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EXECUTIVE  SUMMARY 


INTRODUCTION. 

The  Federal  Aviation  Administration  (FAA)  is  pursuing  an  initiative 
to  develop  and  implement  a  Data  Link  system  to  supplement  and 
enhance  communications  between  ground-based  air  traffic  control 
(ATC)  and  airborne  systems.  For  the  past  4  years,  the  FAA 
Technical  Center  has  supported  this  initiative  through  a  program 
of  research  aimed  at  designing  and  evaluating  initial  ATC  services 
and  functions  for  both  en  route  and  terminal  ATC  environments. 
This  report  presents  the  results  of  the  third  design  development 
(mini)  study  conducted  to  refine  and  test  four  terminal  Data  Link 
ATC  services  and  functions. 

OBJECTIVES . 

The  primary  objective  of  the  study  was  to  evaluate  the  usability 
and  operational  suitability  of  designs  for  initial  terminal  Data 
Link  services  as  modified  by  the  results  of  a  prior  study  conducted 
in  1991.  In  addition,  the  study  was  used  to  examine  controller 
strategies  for  optimizing  the  effectiveness  of  Data  Link 
communications,  and  to  evaluate  a  group  of  system  performance 
measures  for  use  in  future  operational  evaluation  testing. 

These  objectives  were  pursued  in  a  series  of  training  exercises  and 
test  sessions  conducted  under  high  fidelity  simulation  conditions 
at  the  Automated  Radar  Terminal  System  (ARTS)  IIIA  workstations  in 
the  Data  Link  Test  Bed.  Six  ATC  specialists  from  the  Air  Traffic 
Data  Link  Validation  Team  (ATDLVT)  participated  in  the  simulation 
trials  and  subsequent  debriefing  sessions. 

PRIMARY  RESULTS. 

The  design  evaluation  confirmed  the  acceptability  and  utility  of 
the  modifications  introduced  for  this  study.  These  modifications 
included  several  human  factors  design  features  intended  to  enhance 
the  usability  of  the  menu-based  Menu  Text  (MT)  and  Terminal 
Information  (TI)  services.  The  results  also  produced  a  limited 
number  of  additional  design  enhancements  aimed  at  increasing  the 
adaptability  of  the  menu-based  services  to  varying  field 
requirements. 

Simulation  testing  conducted  to  investigate  strategies  for  using 
Data  Link  in  terminal  airspace  showed  that  controllers  were  able 
to  employ  Data  Link  to  accomplish  nearly  all  communications  tasks. 
However,  Data  Link  was  not  judged  suitable  for  time-critical 
communications  used  to  turn  aircraft  onto  final  approach,  deal  with 
missed  approaches,  or  resolve  aircraft  conflicts.  Tests  in  which 
two-controller  teams  staffed  a  combined  arrival/final  approach 
sector  indicated  that,  unlike  the  single  channel  voice  radio 
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system,  a  combined  voice  and  Data  Link  system  could  be  used  to 
reduce  aircraft  delays  under  some  operations  conditions. 

Several  of  the  performance  measures  evaluated  during  the  study 
showed  promise  for  application  to  future  Data  Link  testing.  In  a 
majority  of  cases,  it  was  determined  that  the  use  of  automatically 
collected  measures  of  system  safety,  capacity,  and  efficiency  would 
require  close  coordination  with  controller  strategies  and 
simulation  test  scenarios  as  well  as  supplementary  expert  analyses 
to  insure  their  validity. 

RECOMMENDATIONS . 

The  results  of  the  study  support  the  following  key  recommendations 
regarding  future  terminal  ATC  Data  Link  development  and  testing 
activities: 

1.  The  results  of  the  design  evaluation  indicated  that  the  initial 
terminal  services  have  reached  an  advanced  level  of  development. 
It  is,  therefore,  recommended  that  these  services  be  subjected  to 
operational  evaluation  in  the  Data  Link  Test  Bed.  This  evaluation 
should  involve  validation  of  the  service  designs  through  extensive 
testing  by  a  group  of  ATC  specialists  who  have  not  participated  in 
the  design  development  process. 

2.  In  addition  to  operation  evaluation,  research  should  be 
conducted  to  investigate  unresolved  human  factors  issues  which  have 
emerged  from  the  present  and  other  terminal  Data  Link  studies.  The 
most  important  of  these  issues  are:  (a)  the  comparative  potential 
for  undetected  communications  errors  in  voice  messages  and  Data 
Link  messages,  (b)  the  significance  and  performance  impact  of 
reports  that  short-term  memory  for  manually  entered  Data  Link 
messages  may  be  poorer  than  that  for  voiced  messages,  and  (c)  the 
impact  on  situation  awareness  of  increased  "heads  down"  time  for 
the  Data  Link  controller. 
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1 .  INTRODUCTION . 


1.1  PURPOSE. 

This  document  presents  the  results  of  a  Federal  Aviation 
Administration  ( FAA)  Technical  Center  investigation  of  terminal 
air  traffic  control  (ATC)  services  developed  for  transmission  using 
Data  Link  technology.  Based  on  the  results  of  two  prior  studies 
conducted  in  1990  and  1991,  designs  for  four  ATC  services  were 
modified  and  implemented  in  the  currently  operational  National 
Airspace  System  (NAS)  Automated  Radar  Terminal  System  (ARTS)  IIIA 
computer  and  ATC  workstation  for  review  and  evaluation  by  air 
traffic  controllers. 

The  controllers  participated  in  simulated  terminal  airspace  test 
trials  to  assess  the  utility  of  the  Data  Link  services,  recommend 
requirements  for  additional  service  design  changes,  and  to  examine 
alternative  strategies  for  maximizing  the  effectiveness  of  Data 
Link  communications.  This  study  was  the  third  in  a  planned  series 
of  iterative  design  development  tests  which  will  culminate  in  a 
full-scale  operational  evaluation  and  the  production  of  functional 
design  specifications  for  an  operational  terminal  ATC  Data  Link 
communications  system. 

1.2  BACKGROUND. 

1.2.1  ATC  Communications  and  Data  Link. 

In  response  to  the  phenomenal  growth  of  air  traffic  in  the  United 
States,  the  FAA  has  begun  to  develop  and  implement  a  broad  range 
of  initiatives  aimed  at  updating  and  enhancing  ATC  technology.  Many 
of  these  efforts  are  focused  on  improving  the  quality  and  quantity 
of  information  that  will  be  needed  to  increase  safety  and 
productivity,  and  on  insuring  that  this  information  is  reliably  and 
accurately  transferred  among  the  computers  and  humans  that  form  the 
major  components  of  the  ATC  system. 

One  of  the  primary  information  transfer  problems  that  constrains 
the  capacity  of  the  current  ATC  system  is  the  inherently  limited 
communication  channel  that  exists  between  the  air  traffic 
controller  and  the  aircraft  pilot.  Because  this  voice  radio  link 
operates  in  a  broadcast  mode  between  a  single  controller  and  all 
aircraft  operating  in  the  airspace  under  his  control,  frequency 
congestion  is  a  common  occurrence  when  the  volume  and  complexity 
of  air  traffic  increases.  Such  saturation  of  the  communications 
channel  affects  the  performance  of  the  ATC  system  by  preventing 
the  timely  issuance  of  clearances  and  by  restricting  the  vital 
exchange  of  information  upon  which  safe  and  efficient  operation  of 
the  NAS  depend. 

In  addition  to  the  limitations  that  it  imposes  through  frequency 
congestion,  the  voice  radio  channel  has  been  identified  as  a  major 
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contributor  to  errors  in  the  ATC  system.  The  FAA  has  noted  that 
as  many  as  23  percent  of  all  operational  errors  are  caused  either 
directly  or  indirectly  by  communications  mistakes  (New  York  Times, 
1988) .  Similarly,  compilations  of  voluntary  reports  provided  to 
the  Aviation  Safety  Reporting  System  by  pilots  and  controllers  have 
shown  that  a  majority  of  all  potentially  hazardous  incidents  that 
are  filed  implicate  ineffective  verbal  information  transfer 
(Billings  and  Reynard,  1981) . 

Investigations  of  the  nature  of  prevalent  communications  errors 
demonstrate  that  they  are  typically  the  result  of  an  interaction 
between  the  characteristics  of  the  voice  radio  system  and  the 
inherent  perceptual  and  cognitive  characteristics  of  its  human 
users  (Shingledecker ,  1990) .  Acoustic  confusions,  alphanumeric 
transpositions,  misinterpretation  due  to  pronunciation  and 
phraseology  problems,  poor  memory  for  transient  speech 
presentations  of  ATC  information,  and  blocking  of  the  radio  channel 
caused  by  improper  keying  techniques  are  common  sources  of  human- 
induced  error  found  by  these  studies.  In  addition,  many  errors 
seem  to  be  potentiated  by  the  frequency  congestion  problem  as  users 
experience  difficulty  in  monitoring  for  relevant  messages  on  the 
crowded  radio  channel,  and  become  reluctant  to  clarify  suspected 
confusions  in  order  to  avoid  further  congestion. 

Data  Link  is  a  digital  communications  technology  which  is  being 
developed  as  a  supplement  to  traditional  voice  radio  for  ATC 
communications.  As  shown  in  figure  1,  Data  Link  communications 
can  be  supported  by  several  transmission  media.  These  include  very 
high  frequency  (VHF)  radio,  satellite  links,  and  the  Mode  Select 
(Mode  S)  secondary  surveillance  radar  system  currently  proposed  by 
the  FAA  for  ATC  Data  Link  communications.  These  multiple  links 
will  be  integrated  within  a  common  Aeronautical  Telecommunications 
Network  to  provide  seamless  air-ground  communications  throughout 
the  NAS. 

Regardless  of  the  specific  method  used  to  create  the  channel,  Data 
Link  communications  are  distinguished  from  traditional  voice  radio 
links  in  two  essential  ways.  First,  unlike  analogue  voice 
messages.  Data  Link  messages  consist  of  digitally  coded 
information.  Thus,  data  may  be  entered  for  transmission  either 
manually,  or  by  direct  access  to  information  contained  in  airborne 
or  ground-based  computers.  Furthermore,  the  capability  of  a 
digital  system  to  provide  automatic  error  checking  of  sent  and 
received  messages  makes  Data  Link  a  highly  reliable  system  which 
is  not  susceptible  to  degradation  by  interfering  noise  sources. 

The  second  way  in  which  Data  Link  differs  from  the  voice  radio 
channel  is  its  capability  to  discretely  address  individual 
receivers.  Unlike  the  simplex  radio  system  which  permits  only  a 
single  speaker  to  transmit  on  the  broadcast  frequency  at  any  point 
in  time.  Data  Link  messages  can  be  sent  selectively,  and 
transmission  rates  are  not  artificially  bounded  by  the  effective 
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speaking  and  listening  rates  of  the  user.  As  a  result,  Data  Link 
channels  can  have  a  much  higher  capacity  than  voice  channels  and 
critical  messages  sent  by  a  controller  are  assured  of  receipt  only 
by  the  intended  aircraft. 

These  features  of  Data  Link  offer  significant  promise  for 
alleviating  both  frequency  congestion  and  errors  that  currently 
impair  air-ground  ATC  communications.  As  more  aircraft  are 
equipped  with  Data  Link,  demands  on  the  voice  channel  should  be 
relieved  in  proportion  to  the  number  of  weather  and  ATC  services 
that  are  assigned  to  the  Data  Link  system.  In  addition,  by 
automating  or  simplifying  pilot  and  controller  functions  in  the 
communication  process  that  are  subject  to  error,  Data  Link  should 
improve  the  overall  effectiveness  of  information  transfer.  For 
example,  using  Data  Link  it  will  be  possible  to  reduce  ambiguous 
message  transmissions  by  storing  standard  clearances  in  computer 
memory  for  simplified  uplink  to  an  aircraft;  failures  to  detect 
messages  and  accidental  acceptance  of  clearances  by  unintended 
aircraft  will  be  eliminated  by  discrete  addressing;  interpretation 
errors  should  be  reduced  by  the  availability  of  a  persistent  and 
recallable  visual  display  of  the  received  data;  and  the  system  will 
automatically  verify  the  integrity  of  a  message  without  human 
intervention. 

1.2.2  Data  Link  Research  and  Development  at  the  FAA  Technical 
Center. 

As  noted  above,  the  technical  characteristics  of  Data  Link  have 
the  capability  to  significantly  enhance  the  safety  and  productivity 
of  the  ATC  system.  However,  Data  Link  will  also  introduce  a 
profound  change  in  the  way  in  which  ATC  tasks  are  accomplished  by 
controllers,  and  in  the  way  aircrew  will  receive  and  respond  to  ATC 
instructions.  Because  of  this,  the  ultimate  success  of  Data  Link 
will  be  critically  dependent  on  the  extent  to  which  it  is  employed 
to  create  an  effective  communications  system  that  is  thoroughly 
integrated  with  its  human  users  and  with  the  full  range  of  tasks 
that  they  are  required  to  perform. 

Recognition  of  the  need  to  consider  operational  suitability  and 
human  factors  issues  as  primary  drivers  of  the  design  process 
prompted  the  FAA  Technical  Center  to  initiate  a  program  of  manned 
simulation  research  to  guide  the  development  of  Data  Link  ATC 
services.  The  overall  goals  of  this  research  are  to  (a)  define 
useful  Data  Link  services,  (b)  determine  the  user  information 
requirements  for  Data  Link  communications,  (c)  develop  display 
formats,  data  entry  methods  and  procedures  which  promote  efficient 
controller  performance,  and  (d)  evaluate  the  impact  of  Data  Link 
services  on  both  human  and  system  performance. 

The  Data  Link  Test  Bed  was  assembled  at  the  FAA  Technical  Center 
to  address  these  goals.  The  test  bed  is  a  laboratory  facility 
which  uses  actual  NAS  equipment  in  conjunction  with  simulation 
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computers  to  create  a  system  capable  of  realistically  exercising 
Data  Link  applications  in  an  end-to-end  fashion.  In  its  current 
form,  the  test  bed  is  composed  of  the  NAS  en  route  and  terminal 
laboratories,  the  NAS  System  Simulation  Facility  (NSSF) ,  and  the 
Data  Link  laboratory  (figure  2).  The  NAS  laboratory  includes  the 
HOST  computer  system  used  for  en  route  ATC  data  processing  as  well 
as  its  primary  terminal  counterpart,  the  ARTS  IIIA  system.  Both 
computers  are  linked  to  several  suites  of  their  respective 
operational  controller  workstations  which  are  used  to  display  radar 
data  and  to  enter  system  inputs. 

The  NAS  laboratory  is  linked  to  the  NSSF  through  the  ATC  computers. 
The  NSSF  permits  the  NAS  laboratory  systems  to  act  as  functioning 
control  facilities  by  providing  simulated  radar  data  and  voice 
radio  inputs  from  simulation  ••pilots"  operating  from  computer 
terminals.  Alternatively,  the  ARTS  and  HOST  portions  of  the  NAS 
laboratory  can  be  used  as  self-contained  simulation  systems  using 
the  training  functions  included  within  the  operational  systems. 
In  this  configuration,  pilot  functions  are  performed  by  simulation 
operators  working  at  additional  controller  workstations. 

The  Data  Link  laboratory  houses  a  VAX  11/750  computer  which  acts 
as  an  emulation  of  the  future  ground  Data  Link  processor.  The  VAX 
computer  supports  digital  communication  between  simulation  pilots 
and  controllers.  It  can  also  provide  two-way  communication  between 
controllers  and  high-fidelity  aircraft  simulators  or  actual 
airborne  systems  using  Mode  S  or  any  other  installed  Data  Link 
technology. 

The  central  thrust  of  Data  Link  research  in  the  test  bed  is  manned 
simulation  research  aimed  at  defining  and  testing  designs  for  ATC 
services.  This  research  follows  a  three-stage  approach  originally 
developed  and  successfully  employed  under  the  en  route  portion  of 
the  Data  Link  program.  In  the  Design  Verification  stage, 
engineering  tests  are  conducted  in  the  Data  Link  Test  Bed  to  insure 
that  preliminary  designs  for  Data  Link  services  are  faithfully 
reflected  in  operational  software  and  hardware  components  of  the 
test  bed  simulation  laboratories.  Following  the  resolution  of 
engineering  issues,  a  series  of  manned  simulation  studies  are 
performed  in  which  air  traffic  controllers  exercise  and  evaluate 
the  Data  Link  ATC  services. 

In  the  Mini  Study  stage  of  these  experiments,  iterative  design 
evaluations  are  conducted  to  refine  controller  procedures, 
displays,  and  input  requirements.  Early  studies  are  completed 
under  controlled,  part-task  simulation  conditions  which  focus  on 
detailed  consideration  of  basic  design  issues.  As  development 
progresses,  simulation  exercises  are  increased  in  operational 
fidelity  to  assess  the  robustness  of  the  services  and  to  obtain 
reliable  controller  judgments  of  acceptability,  usability,  and 
workload  effects.  A  fixed  group  of  Fv.ll  Performance  Level  (FPL) 
controllers  from  the  Air  Traffic  Data  Link  Validation  Team  (ATDLVT) 
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FIGURE  2.  THE  DATA  LINK  TEST  BED 


participate  throughout  the  mini  study  stage  to  provide  continuity 
in  the  iterative  development  process. 

The  final  Operational  Evaluation  stage  of  the  approach  consists  of 
one  or  more  high  fidelity  simulation  exercises  in  which  the 
optimized  service  designs  are  exercised  under  a  variety  of 
realistic  operational  conditions  and  air  traffic  scenarios.  For 
these  studies,  a  new  group  of  controllers  with  no  prior  Data  Link 
experience  is  recruited  for  participation.  Measures  of  system 
effectiveness,  controller  performance,  communications  efficiency, 
and  workload  are  used  to  verify  the  utility  and  usability  of  the 
Data  Link  services.  The  resulting  data  determine  inputs  to  a 
Technical  Data  Package  (TDP)  that  is  used  to  guide  the  development 
of  operational  Data  Link  software  for  implementation  in  the  NAS. 

1.3  DATA  LINK  IN  THE  TERMINAL  ENVIRONMENT. 

1.3.1  Development  Issues. 

Research  and  development  using  the  Data  Link  Test  Bed  began  with 
the  en  route  portion  of  the  ATC  system.  Mini  studies  were 
conducted  to  refine  the  transfer  of  communication  and  altitude 
assignment  services  as  well  as  a  Menu  Text  (MT)  function  for 
uplinking  interim  altitudes  with  crossing  restrictions,  and  an 
unformatted  Free  Text  (FT)  function.  These  efforts  culminated  in 
an  operational  evaluation  which  demonstrated  beneficial  effects  of 
the  initial  en  route  services  on  frequency  congestion  with  no 
observed  reduction  in  controller  performance  or  increase  in 
perceived  workload. 

The  potential  value  of  Data  Link  communications  technology  for 
terminal  ATC  operations  is  likely  to  equal  that  predicted  by  the 
results  of  the  operational  evaluation  for  the  en  route  environment. 
At  present,  the  demands  at  busy  airports  often  can  result  in  a 
terminal  controller  engaging  in  prolonged  periods  of  non-stop 
verbal  communication  to  convey  all  of  the  clearances  needed  to 
guide  the  pilots  of  arriving,  departing,  and  transient  aircraft. 
In  addition,  the  requirement  to  convey  lengthy  advisory  messages 
to  aircraft  entering  the  terminal  area  rapidly  expends  the  limited 
communication  time  available  to  tactically  control  closely  spaced 
aircraft  on  the  approach  and  departure  flightpaths. 

While  the  need  to  reduce  frequency  congestion  is  similar  in  the 
terminal  and  en  route  environments,  the  problem  of  designing  an 
effective  Data  Link  system  for  the  two  is  quite  different.  In 
general,  terminal  operations  are  more  sensitive  to  timing  issues 
than  en  route  operations.  Because  of  this,  communications 
functions  assigned  to  Data  Link  must  be  carefully  selected, 
designed,  and  tested  to  ensure  that  transmission  delays  or  display 
clutter  do  not  interfere  with  controller  performance  requirements. 
In  addition,  unlike  some  en  route  clearances,  current  terminal 
procedures  do  not  require  the  use  of  keyboard  inputs  to  update  an 
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ATC  computer  data  base.  This  precludes  the  use  of  simple  keystroke 
additions  to  data  base  update  inputs  as  a  means  to  efficiently 
create  and  send  terminal  ATC  messages.  Consequently,  particular 
attention  must  be  directed  toward  the  design  of  data  entries  which 
minimize  the  workload  of  entering  and  uplinking  control  messages. 
Finally,  the  tactical  nature  of  ATC  operations  in  terminal  airspace 
demands  that  every  effort  be  made  to  ensure  that  Data  Link 
displays,  inputs,  and  procedures  are  sufficiently  flexible  to 
permit  adaptation  to  a  wide  range  of  operational  situations  and 
conditions. 

1.3.2  Initial  Terminal  Services. 

Drawing  from  their  experience  as  terminal  controllers  and  an 
awareness  of  the  design  issues  outlined  above,  the  terminal 
subgroup  of  the  ATDLVT  met  with  FAA  engineers  and  supporting 
contractors  in  a  series  of  meetings  held  in  1989  and  1990  to  define 
an  initial  group  of  ATC  services  suitable  for  the  terminal 
environment.  The  following  services  were  identified  during  these 
meetings: 

a.  Transfer  of  Communication  (TC) .  TC  is  the  message  sent  to 
an  aircraft  after  track  control  has  been  passed  to  a  new  sector 
which  instructs  the  pilot  to  change  radio  frequencies  in  order  to 
communicate  with  the  new  controller.  Using  the  designed  Data  Link 
service,  this  message  is  automatically  prepared  by  the  ATC  computer 
and  uplinked  either  automatically  or  upon  a  controller  input 
action. 


b.  Initial  Contact  (IC) .  When  an  aircraft  receives  a  new 
radio  frequency,  current  ATC  procedures  require  the  pilot  to 
contact  the  new  controller  and  to  report  the  aircraft's  assigned 
altitude  and  the  current  Automatic  Terminal  Information  Service 
(ATIS)  code.  With  the  Data  Link  version  of  IC  tested  during  this 
study,  the  aircraft's  assigned  altitude  is  downlinked  with  the 
"WILCO"  response  to  the  preceding  TC.  This  IC  report  is  passed  to 
the  receiving  sector  through  the  ground  communications  system,  and 
is  presented  to  the  controller  on  the  radar  display. 

c.  Terminal  Information  Service  (TI) .  When  arriving  aircraft 
enter  a  terminal  airspace,  they  are  typically  given  a  report  of  the 
terminal  operating  conditions  and  of  the  approach  clearance  that 
they  can  expect  to  receive.  Using  Data  Link,  these  commonly 
lengthy  messages  are  stored  in  a  menu  and  sent  by  a  single  manual 
input  which  initiates  the  uplink. 

d.  Control  Instructions.  This  group  of  services,  provided  by 
the  Data  Link  function  MT,  permits  the  controller  to  uplink 
altitude,  heading,  and  speed  clearances.  As  tested  in  the  present 
study,  these  messages  could  be  selected  from  a  predefined  menu  or 
composed  in  real-time  using  shorthand  keyboard  inputs. 
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1.3.3  Previous  Design  Development  Studies. 


Development  of  the  initial  terminal  Data  Link  services  began  with 
a  demonstration  of  preliminary  designs  using  a  rapid  prototyping 
system  at  The  MITRE  Corporation.  In  1990,  the  services  were 
implemented  in  the  ARTS  IIIA  computer  and  integrated  with  the  Data 
Link  Test  Bed.  The  first  mini  design  study  of  these  services  at 
the  FAA  Technical  Center  was  conducted  in  late  1990  to  establish 
a  developmental  baseline  (Data  Link  Development  Team,  1991) . 

A  second  study  was  completed  in  1991  to  evaluate  versions  of  the 
initial  services  which  had  been  modified  on  the  basis  of 
recommendations  obtained  from  the  ATDLVT  participants  during  the 
first  study  (Talotta,  et  al.,  1992).  The  second  Mini  Study  also 
examined  the  effects  of  Data  Link  transaction  times  on  the  utility 
of  the  terminal  services.  Results  obtained  from  the  design  review 
suggested  that  additional  improvements  in  the  effectiveness  of  the 
tested  Data  Link  services  could  be  achieved  by  introducing  design 
modifications  to  increase  the  usability  and  flexibility  of  the 
menu-based  services,  the  history  list,  the  TC  service,  and  the  IC 
function. 

The  study  described  in  this  document  was  conducted,  in  part,  to 
evaluate  the  effectiveness  of  the  alterations  made  to  the  Data  Link 
service  designs  as  a  result  of  these  findings. 

1.4  ORGANIZATION  OF  THE  REPORT. 

The  following  sections  of  this  report  present  the  research 
methodology  that  was  used  and  the  findings  that  were  obtained  in 
the  third  FAA  Technical  Center  controller  evaluation  study  of  Data 
Link  terminal  ATC  services.  Section  2  describes  the  specific 
objectives  of  the  study  and  the  testing  approach  that  was  used  to 
achieve  these  objectives.  Section  3  presents  the  detailed  results 
of  the  testing.  Finally,  sections  4  and  5  list  the  conclusions 
that  were  derived  from  the  results  and  offer  recommendations  for 
future  efforts  toward  the  development  of  an  operational  terminal 
Data  Link  system. 

2.  TEST  DESCRIPTION. 

2 . 1  OBJECTIVES . 

This  study  was  conducted  to  meet  the  following  major  objectives: 

a.  Evaluate  the  acceptability  of  enhanced  designs  for  the 
initial  Data  Link  terminal  services. 

As  noted  above,  the  results  of  the  second  terminal  Mini  Study 
included  recommendations  for  changes  to  the  ATC  service  designs  as 
implemented  on  the  ARTS  IIIA  equipment  in  the  Data  Link  Test  Bed. 
Controllers  participating  in  this  third  study  evaluated  the 
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modified  displays  and  procedures  to  determine  the  adequacy  and 
acceptability  of  the  enhanced  service  designs.  The  modifications 
examined  during  the  study  included: 


1.  Addition  of  shorthand  message  content  data  to  the 
status  list  and  data  block  transaction  status  displays. 

2.  Reduction  in  the  length  of  the  history  list  and 
relocation  to  the  status  list  position. 

3.  Redesign  of  the  IC  service  to  eliminate  the  altitude 
request  transaction. 

4.  Use  of  different  message  identifier  labels  in  the  TI 
and  MT  lists. 

5.  Addition  of  the  ability  to  independently  reposition 
and  suppress  the  TI  and  MT  lists. 

6.  Addition  of  the  ability  to  suppress  individual  items 
in  the  TI  and  MT  lists  to  reduce  display  clutter. 

7.  Relocation  of  the  automatic/hold  mode  display  for  TC, 
and  addition  of  the  ability  to  initiate  a  sector  handoff  while  a 
transaction  is  in  progress. 

8.  Multiple  modifications  to  the  MT  service  to  simplify 
item  selection  and  increase  the  applicability  of  individual  menu 
items  through  automation. 

The  evaluation  also  addressed  several  general  design  and  procedural 
issues  which  had  been  revealed  during  the  prior  study.  These 
included: 

1.  Definition  of  allowable  content  of  messages  included 
in  the  TI  list. 

2.  Requirements  for  unstructured  messages  in  the  MT  list. 

3.  Input  error  potential  when  entering  messages  for 

uplink. 

4.  Appropriate  procedures  following  message  transmission 
failures  and  message  delete  entries. 

b.  Examine  controller  strategies  for  optimizing  the 
effectiveness  of  Data  Link  communications. 

Beyond  the  consideration  of  basic  design  problems,  the  present 
study  also  was  used  to  provide  an  initial  exploration  of 
communications  procedures  and  approaches  that  could  be  used  to 
enhance  Data  Link  effectiveness.  Prior  research  with  both  en  route 
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and  terminal  controllers  has  suggested  that  optimal  application  of 
Data  Link  may  require  modifications  to  current  ATC  procedures  in 
which  only  a  single  channel  of  communication  is  available.  In 
order  to  more  thoroughly  explore  and  document  potential  Data  Link 
communications  strategies,  test  subjects  in  this  study  participated 
in  full  scale  simulation  exercises  in  which  current  voice  radio 
procedures  were  compared  to  combined  voice  and  Data  Link 
communications.  For  these  test  runs,  the  arrival  and  final 
approach  sectors  used  in  heavy  traffic  simulation  scenarios  were 
combined  at  single  control  positions.  The  subjects  operated  these 
positions  either  as  single  controllers  or  as  two  controller  teams. 

The  purpose  of  these  manipulations  was  to  provide  the  controllers 
with  an  ATC  situation  in  which  they  could  explore  and  compare 
alternative  strategies  of  communication  in  the  voice-only  and  voice 
and  Data  Link  conditions.  The  subjects'  strategies  and  evaluations 
of  their  effectiveness  were  documented  using  questionnaires 
completed  after  each  test  run,  individual  interviews,  post-test 
comparative  ratings,  and  group  discussions. 

c.  Evaluate  the  utility  and  validity  of  a  group  of 
experimental  system  and  control] cr  performance  measures  for  use  in 
future  operational  evaluation  studies. 

The  final  objective  of  this  study  was  to  evaluate  a  set  of 
performance  measures  for  use  in  future  operational  evaluation 
research.  These  quantitative  measures  will  be  required  for  this 
research  in  order  to  supplement  expert  controller  opinions  with 
objective  indicators  of  Data  Link’s  impact  on  ATC  communications 
efficiency  and  on  overall  ATC  system  performance.  The  experimental 
performance  measures  were  collected  automatically  by  the  simulation 
computers  during  full  scale  test  runs  and  evaluated  for  sensitivity 
and  applicability  to  Data  Link  operational  evaluation  research 
questions . 

2.2  APPROACH. 

The  approach  that  was  adopted  to  meet  the  objectives  of  this  study 
involved  the  participation  of  terminal  air  traffic  controllers  in 
a  series  of  training  exercises,  test  sessions,  and  structured 
debriefings.  The  simulation  test  trials  were  conducted  at  the  ARTS 
IIIA  workstations  in  the  Data  Link  Test  Bed.  During  testing, 
subjects  controlled  traffic  in  a  group  of  ATC  scenarios  involving 
aircraft  arrivals  and  departures  at  the  Raleigh/Durham  (RDU) 
Airport. 

Early  test  sessions  were  devoted  to  a  detailed  review  of  each  of 
the  four  Data  Link  service  designs  as  modified  by  the  results  of 
the  second  Mini  Study.  Individual  reviews  were  supplemented  by 
debriefings  aimed  at  achieving  group  consensus  and  documenting 
unresolved  design  and  procedural  issues. 
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Later  sessions  were  used  to  compare  voice  radio  air-ground 
communications  to  a  system  supplemented  by  Data  Link  under  full 
scale  simulation  conditions.  Air  traffic  loads  were  increased  from 
moderate  to  high  levels  over  the  course  of  each  test  session.  In 
half  of  the  voice  sessions  and  half  of  the  Data  Link  sessions,  the 
test  subjects  worked  in  two  controller  teams.  The  division  of 
duties  in  these  sessions  was  determined  by  the  team  members. 

During  full  scale  simulation,  voice  radio  and  Data  Link  usage,  as 
well  as  a  number  of  experimental  performance  measures,  were 
recorded  automatically  by  the  simulation  system.  Following  each 
run,  the  controllers  completed  questionnaires  intended  to  document 
their  communication  and  control  strategies.  Post-test  scales  were 
used  to  obtain  controller  projections  of  the  impact  of  team  size 
and  Data  Link  on  workload,  system  capacity,  and  safety.  Finally, 
individual  subject  interviews  and  group  discussions  were  conducted 
to  further  document  controller  strategy  differences  between  voice- 
only  and  voice  plus  Data  Link  communication  conditions. 

The  general  rationale  underlying  the  test  design  was  to  provide  an 
ATC  environment  which  could  be  used  by  the  controllers  to  assess 
the  capabilities  and  robustness  of  the  service  designs  against 
relatively  realistic  operational  conditions,  and  to  explore  the 
effectiveness  of  Data  Link  under  various  individual  and  team 
communication  strategies. 

2.3  TEST  CONDUCT. 

2.3.1  Subjects. 

The  subjects  for  this  study  were  eight  FPL  ATC  specialists  with 
current  terminal  radar  control  experience.  All  subjects  were  drawn 
from  the  membership  of  the  ATDLVT .  Six  of  the  subjects  had 
participated  during  the  conceptual  development  of  the  initial  Data 
Link  terminal  ATC  services  and  had  acted  as  test  subjects  in  prior 
mini  studies. 

2.3.2  Test  Scenarios  and  Data  Link  Operations. 

The  ATC  scenarios  developed  for  this  study  utilized  the  RDU 
terminal  airspace.  The  airspace,  local  ATC  procedures,  and  test 
scenarios  used  during  training  and  testing  are  presented  in  detail 
in  appendix  A  of  this  report  and  are  briefly  described  below. 

Traffic  patterns  and  procedures  used  in  the  scenarios  were 
identical  to  those  used  at  the  operational  facility.  The  single 
exception  was  that  simultaneous  approaches  to  the  parallel  runways 
were  permitted  in  the  simulation,  whereas  staggered  approaches  are 
required  at  RDU.  Incoming  aircraft  were  routed  through  two 
arrival  sectors  located  to  the  east  and  west  of  the  airport. 
During  the  design  review  scenarios,  each  arrival  controller 
accepted  aircraft  handed  off  from  the  Washington  Air  Route  Traffic 
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Control  Center  (ARTCC)  over  two  fixes.  Overflight  aircraft  were 
given  clearances  for  their  destination  airports,  while  RDU  arrivals 
were  established  on  a  downwind  leg  or  on  headings  for  final 
approach  before  control  was  transferred  to  the  associated  final 
approach  sector.  Each  final  controller  merged  the  two  streams  of 
aircraft  received  from  his  arrival  sector  and  issued  the  approach 
clearances.  Controllers  in  the  two  departure  sectors  (north  and 
south  departure)  each  directed  aircraft  to  one  of  two  departure 
fixes  according  to  their  flight  plans.  In  both  sectors,  one  of  the 
departure  streams  crossed  an  arrival  route.  This  required  the 
controllers  to  insure  that  the  departing  aircraft  met  specific 
altitude  restrictions  while  crossing  the  arrival  route. 

During  the  full  scale  simulation  runs,  the  six  sectors  were  reduced 
to  four  by  combining  the  arrival  and  final  approach  sectors  on  each 
side  of  the  airport.  In  half  of  the  test  runs,  each  of  these 
combined  sectors  was  staffed  by  a  single  controller,  while  in  the 
other  half  they  were  staffed  by  a  two  controller  team. 

The  mix  of  aircraft  types  used  in  all  scenarios  was  derived  from 
records  for  RDU  contained  in  the  Official  Airline  Guide  (OAG) . 
General  aviation  traffic  not  shown  in  the  OAG  was  added  to  the 
scenarios  to  enhance  realism.  All  scenarios  used  during  full  scale 
simulation  testing  presented  traffic  loads  which  increased  over  the 
course  of  a  run  from  the  equivalent  of  75  percent  to  145  percent 
of  the  RDU  arrival  acceptance  rate.  The  scenarios  differed  from 
one  another  only  in  the  sequence  and  spacing  of  arrivals  and 
departures.  Traffic  sequences  were  controlled  so  that  aircraft 
type  or  speed  when  crossing  the  outer  fixes  would  not  introduce 
confounding  differences  between  the  complexity  of  the  test 
scenarios.  Reduced  traffic  levels  were  used  during  training  and 
during  the  design  review  phase  of  testing. 

Pilot  functions  for  this  study  were  provided  by  the  NSSF.  Pseudo¬ 
pilots  received  voice  and  Data  Link  messages  from  the  controllers 
and  made  inputs  on  specialized  computer  terminals  to  control  the 
simulated  aircraft  radar  tracks.  When  responding  to  voice  radio 
instructions,  the  pseudo-pilots  acknowledged  clearances  in  the 
normal  fashion  with  a  voice  response  to  the  controller.  Precise 
control  of  the  elapsed  time  between  the  issuance  of  a  Data  Link 
message  and  receipt  of  a  confirming  response  was  achieved  by  using 
the  VAX  computer  to  automatically  generate  and  send  the  pilot 
acknowledgement  to  the  controller  via  Data  Link.  In  order  to 
produce  realistic  temporal  coordination  between  aircraft 
maneuvering  responses  and  downlinked  pilot  responses,  the  VAX 
computer  was  programmed  to  withhold  displaying  messages  to  the 
pseudo-pilots  until  approximately  8  seconds  before  the 
acknowledgement  was  sent  to  the  controller. 
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2.3.3  Test  Procedures. 


This  study  was  conducted  over  a  6-day  period.  The  first  day  was 
devoted  to  subject  prebriefings  and  training.  Data  collection  began 
on  the  second  day  with  individual  subject  reviews  of  the  Data  Link 
terminal  service  designs  and  a  debriefing  session.  The  third  and 
fourth  days  and  half  of  the  fifth  day  were  used  to  train  the 
controllers  on  the  combined  arrival/final  configuration  and  to 
complete  12  full  scale  simulation  tests  under  voice-only  and  Data 
Link  conditions.  The  last  half  of  the  fifth  day  was  reserved  for 
strategy  interviews  with  the  individual  subjects  and  structured 
discussion.  On  the  final  day,  the  subjects  participated  in  a  group 
debriefing  covering  the  service  designs  and  Data  Link  procedures. 

2. 3. 3.1  Airspace  and  Data  Link  Training. 

To  simplify  airspace  familiarization,  the  eight  subjects  were 
divided  into  two  groups  and  assigned  to  either  the  north  or  south 
halves  of  the  airspace.  The  subgroups  of  four  controllers  were 
required  to  learn  the  arrival,  final,  and  departure  sectors  only 
for  their  assigned  half  of  the  airspace.  These  assignments  were 
maintained  throughout  the  experiment. 

Classroom  training  time  requirements  were  minimized  by  providing 
each  subject  with  a  study  booklet  of  materials  approximately 
2  weeks  prior  to  the  study.  This  booklet  included  the  RDU  airspace 
procedures  and  maps,  as  well  as  detailed  descriptions  of  the  Data 
Link  service  inputs  and  displays.  When  the  subjects  arrived  at  the 
test  site  on  the  first  day,  they  received  a  1-hour  review  of  the 
airspace  and  Data  Link  procedures.  After  all  questions  had  been 
answered,  the  subjects  were  taken  to  the  Data  Link  Test  Bed  for  2 
hours  of  simulator  practice  under  the  normal  six  sector  airspace 
configuration . 

The  first  hour  of  practice  was  used  to  familiarize  the  subjects 
with  the  RDU  airspace  and  traffic  flow.  All  communications  were 
conducted  using  voice  procedures.  The  second  hour  of  training  was 
devoted  to  the  displays,  manual  inputs,  and  procedures  for  using 
the  initial  terminal  Data  Link  services.  For  these  practice 
sessions,  75  percent  of  the  aircraft  in  the  test  scenarios  were 
equipped  with  Data  Link  in  order  to  provide  experience  with 
combined  voice  and  Data  Link  communications. 

2. 3. 3 .2  Design  Review. 

Data  collection  for  this  study  began  with  a  formal  review  and 
verification  of  the  ATC  service  designs  as  modified  by  the  results 
of  Mini  Study  2.  The  subjects  completed  the  2-1/2  hour  design 
review  in  the  Data  Link  Test  Bed  while  seated  at  the  ARTS  IIIA 
workstations  and  controlling  aircraft  in  a  simplified  version  of 
the  six -sector  training  scenario.  All  aircraft  in  the  scenario 
were  Data  Link  equipped  in  order  to  maximize  the  subjects' 
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opportunities  to  examine  the  service  displays,  inputs,  and 
procedures.  To  permit  observation  of  the  failure  displays, 
approximately  5  percent  of  the  attempted  uplinks  resulted  in  a 
failed  technical  acknowledgement  (NAK) ,  5  percent  in  a  timeout 
(failure  of  the  pilot  to  respond  to  an  uplink  within  40  seconds), 
and  5  percent  in  an  unable  response  from  the  pilot. 

During  the  design  review,  the  subjects'  primary  task  was  to 
exercise  each  of  the  Data  Link  functions  a  sufficient  number  of 
times  to  thoroughly  evaluate  the  service  designs.  Evaluations  were 
made  by  completing  a  questionnaire  booklet  during  the  simulation 
runs.  The  subjects  were  informed  that  the  object  of  the  simulation 
activity  was  to  aid  them  in  completing  the  detailed  design  review, 
and  that  maintaining  routine  control  over  the  moderate  (50  percent 
of  capacity)  level  of  air  traffic  in  the  scenario  was  secondary  to 
this  task.  The  subjects  rotated  among  the  sectors  to  permit  each 
individual  the  opportunity  to  examine  all  services.  Test 
facilitators  assigned  to  each  sector  were  available  to  assist  the 
subjects  or  to  answer  any  questions  about  Data  Link  operations. 

The  individual  design  reviews  completed  in  the  test  bed  were 
followed  by  two  debriefing  sessions.  The  first  of  these  was  held 
immediately  after  the  test  bed  activity.  In  this  2-hour  session, 
subjects  met  with  test  personnel  to  perform  an  item-by-item  review 
of  their  responses  to  the  design  review  questionnaire.  A  4 -hour 
session  was  held  on  the  final  day  of  the  study.  This  debriefing 
was  scheduled  to  take  advantage  of  the  additional  experience  with 
the  Data  Link  services  that  the  subjects  had  gained  by 
participating  in  the  intensive,  full  scale  simulation  exercises. 
The  emphasis  of  the  debriefing  was  to  identify  and  resolve 
disagreements  regarding  the  fidelity  and  acceptability  of  the 
service  designs,  and  to  achieve  a  consensus  regarding  recommended 
changes  to  the  service  designs.  The  results  of  both  debriefings 
were  documented  in  test  personnel  notes  and  in  an  audio  tape  record 
for  reference  during  data  analysis. 

2. 3. 3. 3  Full  Scale  Simulation. 

The  second  major  component  of  this  study  was  a  series  of  full  scale 
simulation  tests  in  which  the  subjects  controlled  aircraft  in  the 
RDU  adaptation  using  a  modified  airspace  configuration.  For  these 
tests,  the  arrival  and  final  approach  sectors  on  each  side  of  the 
airspace  were  combined  to  create  single  control  positions.  The 
purpose  of  the  test  runs  was  tn  (t)  examine  strategies  for 
employing  Data  Link  in  single  controller  and  two  controller  teams, 
(2)  compare  Data  Link  strategies  to  those  adopted  under  voice  radio 
communication  conditions,  and  (3)  evaluate  a  group  of  candidate 
measures  of  communication  and  ATC  system  performance  for  use  in 
future  operational  evaluation  tests. 

Data  collection  for  the  full  scale  simulation  was  preceded  by 
2  hours  of  practice  with  the  four  sector  airspace  configuration 
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(two  arrival/final  and  two  departure  sectors) .  Following  a  1-hour 
group  discussion  of  the  communication  and  control  strategies 
attempted  during  practice,  the  subjects  participated  in  12  test 
runs. 

The  independent  variables  that  were  manipulated  during  these  test 
runs  were  the  communication  condition  and  the  number  of  active 
controllers  at  the  combined  arrival/final  sectors.  As  shown  in 
table  1,  voice  radio-only  communications  trials  were  alternated 
with  trials  in  which  both  voice  and  Data  Link  communications  were 
available.  For  Data  Link  test  runs,  80  percent  of  the  aircraft 
were  equipped  with  Data  Link  communications,  while  the  remaining 
20  percent  could  communicate  only  by  voice  radio. 

During  the  first  six  test  runs,  the  combined  arrival/final  sector 
was  staffed  by  a  single  controller.  For  the  last  six  runs,  two 
controllers  acted  as  a  team  at  each  combined  sector.  As  shown  in 
table  1,  the  four  controllers  assigned  to  each  half  of  the  airspace 
rotated  through  each  of  four  stations  during  the  12  runs.  During 
a  test  run,  three  of  the  controllers  from  each  side  of  the  airspace 
were  assigned  to  the  combined  arrival/final  sector.  One  of  these 
was  always  designated  as  the  radar  controller.  During  the  first 
six  runs,  the  other  two  controllers  acted  as  observers.  During  the 
last  six  runs,  one  of  these  acted  as  an  assistant  to  the  radar 
controller  and  the  other  acted  as  an  observer.  On  each  run,  the 
fourth  subject  controlled  traffic  in  the  departure  sector.  The 
rotation  was  balanced  so  that  within  their  assigned  airspace,  each 
subject  participated  as  an  active  controller  under  both  voice  and 
Data  Link  communication  conditions. 

The  subjects  were  not  given  explicit  guidance  regarding  appropriate 
strategies  for  controlling  traffic  in  the  combined  sectors  or  for 
dividing  their  duties  when  performing  on  two  controller  teams. 
Whether  acting  as  observers  or  active  controllers,  all  subjects 
seated  at  the  combined  sectors  were  encouraged  to  participate  in 
the  process  of  generating  and  evaluating  methods  for  employing  the 
voice  and  Data  Link  communications  channels. 

For  all  test  runs,  traffic  loads  in  the  departure  sectors  were 
fixed  at  100  percent  of  accepted  operations  per  hour  at  RDU.  In 
the  combined  arrival/final  sectors,  traffic  load  increased  during 
each  40-minute  test  run  from  75  percent  to  approximately  145 
percent  of  the  RDU  arrival  acceptance  rate.  The  purpose  of  this 
manipulation  was  to  permit  an  examination  of  the  relationship 
between  control  strategies  and  the  ability  of  the  subjects  to 
handle  increasing  levels  of  traffic. 

The  average  total  time  which  elapsed  between  the  initiation  of  an 
uplink  by  the  controller  and  the  receipt  of  a  pilot  acknowledgement 
was  randomly  selected  from  a  rectangular  distribution  with  a  mean 
of  17  seconds,  and  a  range  of  13  to  21  seconds.  These  nominal 
delays  were  selected  based  on  simulation  research  in  which  pilot 
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TABLE  1.  EXPERIMENTAL  DESIGN  FOR  FULL  SCALE  SIMULATION 


Run  Test 
Order  Condition 


Subject/ Posit ion 
Assignment 


SI 


S2 


S3 


S4 


N1 


N2 


N3 


M 


D2 

1 

D 

- 

1 

VI 

2 

V 

- 

1 

S 

D3 

3 

D 

- 

1 

c 

V2 

4 

V 

- 

1 

e 

D1 

5 

D 

- 

1 

n 

V3 

6 

V 

- 

1 

a 

D2 

7 

D 

- 

2 

r 

V3 

8 

V 

- 

2 

i 

D1 

9 

D 

- 

2 

o 

V2 

10 

V 

- 

2 

D3 

11 

D 

- 

2 

VI 

12 

V 

- 

2 

D  0  C  0 
C  0  D  0 
0  C  0  D 
D  O  C  0 
C  0  D  0 
0  C  0  D 
D  O  C  0 
C  D  O  C 
C  C  0  D 
D  C  C  0 
C  D  O  C 
C  0  0  D 


D  0  C  0 
C  O  D  O 
O  C  O  D 
D  0  C  O 
C  O  D  O 
O  C  O  D 
D  O  C  O 
C  D  O  C 
C  C  O  D 
D  C  C  O 
C  D  O  C 
C  O  O  D 


Key: 

Subjects:  Sn  =  South 
Nn  =  North 

Test 

Condition:  D  -  1  =  Data  Link  and  Voice  -  A/F  1  Controller 
D  -  2  =  Data  Link  and  Voice  -  A/F  2  Controllers 
D  -  1  =  Voice  Only  -  A/F  1  Controller 
D  -  2  =  Voice  Only  -  A/F  2  controllers 

Control  Positions:  C  =  A/F  Controller 

D  =  Departure  Controller 
O  =  Observer 
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response  times  to  Data  Link  messages  have  been  recorded,  and  on 
engineering  estimates  of  Mode  S  Data  Link  transmission  times. 

2.3.4  Data  Collection. 

2. 3. 4.1  Design  Review  Materials. 

The  questionnaire  booklet  used  for  the  design  review  was  similar 
to  that  developed  for  the  first  and  second  terminal  mini  studies. 
For  the  present  study,  the  review  booklet  was  organized  in  seven 
sections  (see  appendix  B) .  The  first  section  addressed  general 
system  features  and  procedures  common  to  all  services.  The  second 
through  sixth  sections  covered  the  designs  of  the  transaction 
status  list  and  data  block  status  displays,  the  history  list,  the 
IC  service,  the  TI  service,  the  TC  service,  and  the  MT  function 
used  for  sending  speed,  heading,  and  altitude  clearances.  The 
final  section  considered  issues  surrounding  the  general  design  and 
structure  of  the  menu-based  TI  and  MT  functions. 

Questions  relevant  to  each  of  the  first  six  topics  were  prefaced 
by  a  text  description  of  the  operational  features  relevant  to  the 
function  or  service.  Initial  questionnaire  items  verified  the 
fidelity  with  which  the  test  bed  service  implementations  reflected 
the  design  modifications  introduced  for  this  study  by  requiring  the 
subjects  to  judge  the  correspondence  between  the  descriptions  and 
their  actual  test  bed  experience.  Succeeding  items  assessed  the 
acceptability  of  the  service  implementations  and  associated 
procedures  observed  in  the  test  bed,  and  solicited  recommendations 
for  any  further  design  modifications.  The  seventh  topic  was 
addressed  by  a  set  of  rating  scales  which  were  used  to  evaluate 
requirements  for  free  text  vs.  structured  list  items  and  the 
utility  of  several  controller  interface  features  intended  to 
enhance  performance  when  locating  and  selecting  menu  items. 

2. 3. 4. 2  Strategy  Assessment  Methods. 

In  addition  to  group  discussions  conducted  after  the  practice 
session  and  after  the  study  was  completed,  three  formal  techniques 
were  used  to  document  the  strategies  that  the  subjects  adopted  when 
using  voice  radio  and  Data  Link  communications  when  acting  as 
single  controllers  and  when  working  in  two  controller  teams.  The 
first  of  these  was  a  questionnaire  administered  immediately  after 
each  test  run  during  full  scale  simulation. 

In  all  test  conditions,  the  questionnaire  asked  the  subjects  to 
describe  their  general  strategy  for  controlling  the  aircraft  in 
the  arrival/final  sector,  and  any  modifications  that  they  made  as 
traffic  load  increased  during  the  test  run.  In  addition,  the 
subjects  were  instructed  to  record  and  describe  any  aircraft 
separation  violations  that  had  occurred  in  the  combined  sector. 
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In  test  conditions  where  two  controllers  staffed  the  sector,  the 
team  also  was  asked  to  indicate  how  they  had  divided  their  general 
duties  and  communications  (voice  and/or  Data  Link)  during  the  run. 
In  addition,  questionnaires  completed  after  Data  Link  test  runs 
included  items  which  asked  the  subjects  to  describe  the  types  of 
messages  sent  by  Data  Link  and  any  changes  they  had  made  to  the  TI 
and  MT  lists  for  the  run.  Appendix  C  contains  a  sample  of  the 
questionnaire  used  after  Data  Link  test  runs  with  two  controllers. 

The  second  method  used  to  capture  information  on  controller 
strategies  was  an  interview  technique  employed  after  all  12  test 
runs  had  been  completed.  The  interviews  were  divided  into  two 
parts  and  were  administered  to  the  subjects  individually  by  test 
personnel  who  also  recorded  their  responses.  The  first  part  of 
the  interview  was  a  series  of  questions  intended  to  document  each 
subject's  summary  responses  regarding  the  strategies  used  in  single 
controller  and  two  controller  team  conditions  when  voice-only  and 
Data  Link  communications  were  available.  Additional  interview 
questions  asked  the  subjects  to  judge  the  effectiveness  of  team  and 
individual  strategies  under  the  voice  and  Data  Link  conditions,  and 
to  describe  the  communication  mode(s)  used  to  send  each  type  of  ATC 
service  and  message. 

The  second  part  of  the  interview  used  a  "critical  incident" 
technique  to  more  fully  explore  the  strategies  used  by  the 
controllers  during  test  runs  in  which  Data  Link  communications  were 
available.  For  the  purpose  of  this  study,  a  critical  incident  was 
defined  as  a  challenging  event  which  required  the  controller  to 
apply  skilled  ATC  interventions,  and  in  which  the  controller  had 
a  choice  to  use  voice  or  Data  Link  to  resolve  the  situation. 

The  interviewers  prompted  each  controller  to  recall  one  or  more 
critical  incidents,  and  then  asked  them  to  fully  describe  each 
incident,  construct  timelines  of  the  events  that  occurred,  and 
identify  points  on  the  timelines  where  decisions  to  use  voice  or 
Data  Link  were  taken.  The  materials  used  in  both  parts  of  the 
interview  are  included  in  appendix  C. 

The  final  method  used  for  strategy  assessment  was  a  post-test 
questionnaire  that  was  developed  to  quantify  each  participant's 
expert  opinion  on  how  the  number  of  controllers  staffing  a  sector 
and  the  availability  of  Data  Link  would  affect  perceived  workload, 
the  capacity  of  the  system,  and  overall  safety.  A  sample  of  the 
rating  form  used  to  obtain  these  judgments  is  presented  in  appendix 
C.  For  each  of  the  three  factors,  the  respondents  made  all  six 
comparisons  between  pairs  of  the  four  test  conditions: 

1  controller  -  Voice 

1  controller  -  Voice  and  Data  Link 

2  controllers  -  Voice 

2  controllers  -  Voice  and  Data  Link 
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In  each  comparison,  they  could  rate  the  two  members  of  the  pair  as 
equal  on  the  factor  (e.g.,  workload),  or  judge  either  of  the  two 
as  "somewhat"  or  "much  higher"  on  that  dimension.  The  resulting 
data  were  transformed  to  using  the  Analytical  Hierarchy  Process 
(AHP)  to  produce  ratio  scale  values  for  each  test  condition. 

2. 3. 4. 3  Experimental  Performance  Measures. 

In  addition  to  the  strategy  assessments,  a  candidate  group  of 
objective  performance  metrics  were  collected  during  the  full  scale 
simulation  tests  in  order  to  determine  their  feasibility  for  use 
in  future  operational  evaluation.  These  measures  included 
controller  use  of  the  communications  system  and  indices  of  ATC 
system  performance. 

Because  one  of  the  proposed  benefits  of  an  air-ground  Data  Link  is 
a  reduction  in  voice  radio  frequency  congestion,  data  were 
collected  during  the  simulation  runs  to  gauge  the  use  of  the  voice 
radio  and  Data  Link  by  the  subject  controllers.  Radio  usage  was 
assessed  by  automatically  detecting  the  occurrence  of  all  push- 
to-talk  activations  and  deactivations  of  the  controllers' 
microphone  when  speaking  to  the  simulation  pilots.  Recordings  of 
these  events  yielded  measures  of  the  number  of  controller  initiated 
voice  transmissions  during  a  test  run  and  of  the  amount  of  time  the 
radio  channel  was  occupied  by  controller  transmissions.  The  number 
of  Data  Link  transactions  initiated  by  the  controllers  were 
automatically  recorded  by  the  VAX  computer  which  acts  as  an 
emulation  of  the  future  Data  Link  Processor  and  is  responsible  for 
handling  all  digital  communications  in  the  Data  Link  Test  Bed. 

System  performance  indices  that  were  collected  included  measures 
of  the  degree  of  spatial  separation  among  aircraft  and  of  the 
efficiency  with  which  aircraft  were  handled  by  the  controllers  as 
they  moved  through  the  test  airspace. 

Separation  measures  recorded  by  NSSF  computers  included  the  number 
of  times  two  aircraft  came  within  1,000  feet  vertically  or  3  miles 
horizontally  of  one  another,  as  well  as  the  amount  of  time  that  the 
aircraft  spent  within  these  proximity  limits.  The  computers  also 
recorded  two  additional  separation  measures:  the  Closest  Point  of 
Approach  (CPA)  and  the  Aircraft  Proximity  Index  (API) .  The  CPA  is 
a  non-weighted  calculation  of  the  shortest  slant  range  distance 
between  two  aircraft  within  the  proximity  limits.  The  API  is 
calculated  from  an  algorithm  which  compensates  for  differences  in 
vertical  and  horizontal  separation  limits  by  using  a  weighted 
combination  of  the  distances.  The  API  vertical  component  is 
weighted  approximately  18  times  greater  than  the  horizontal 
component  and  the  resulting  score  ranges  from  0  to  100,  with  100 
indicating  a  collision  between  the  aircraft. 

Efficiency  measures  also  were  collected  by  the  NSSF  computer. 
These  included  the  distance  flown  by  each  aircraft  within  a  sector, 
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the  time  spent  within  a  sector,  the  number  of  controller  initiated 
path  changes,  and  estimated  fuel  expenditure.  Capacity  was 
examined  by  a  minute-to-minute  assessment  of  the  number  of  aircraft 
handled  by  each  controller,  the  spacing  between  landing  aircraft 
as  they  crossed  the  runway  threshold,  and  the  rate  at  which 
aircraft  crossed  the  runway  threshold. 

3 .  TEST  RESULTS . 

3.1  TERMINAL  DATA  LINK  SERVICES  DESIGN  REVIEW. 

A  primary  objective  of  this  study  was  to  evaluate  the  terminal  Data 
Link  service  designs  as  modified  by  the  findings  of  the  second  mini 
design  study.  The  following  subsections  of  this  report  present  the 
results  of  this  evaluation  derived  from  the  individual  design 
review  booklets  and  subsequent  group  debriefing  sessions. 

3.1.1  General  System  Features. 

Prior  terminal  Data  Link  studies  have  defined  several  basic  human 
interface  and  procedural  design  features  which  are  common  to  the 
use  of  all  initial  ATC  services.  These  features  include  keyboard 
assignments  for  special  function  keys,  symbology  used  for  the  Data 
Link  equipage/eligibility  indicator,  and  basic  procedures  governing 
the  conditions  under  which  a  Data  Link  transaction  can  be  initiated 
by  the  controller.  The  results  of  the  present  study  confirmed  the 
acceptability  of  these  general  features  and  defined  additional 
requirements  for  the  time  out  function,  procedures  associated  with 
the  use  of  the  transaction  delete  command,  the  utility  of  the 
resend  input  option,  and  the  need  for  a  global  function  to  restore 
suppressed  displays. 

3. 1.1.1  Timeout  Status  Message. 

In  the  tested  design,  the  third  line  of  the  full  data  block  and 
the  status  list  present  a  message  to  the  controller  if  a  pilot 
fails  to  respond  to  a  delivered  message  within  40  seconds.  In  the 
case  of  the  data  block,  the  "time  out"  message  is  a  flashing  "T". 

Earlier  versions  of  the  Data  Link  time  out  message  terminated  the 
transaction,  and  locked  out  any  response  that  the  pilot  may  have 
sent  after  the  expiration  of  the  timer.  During  the  second  Mini 
Study,  the  participating  controllers  decided  that  the  timeout 
message  should  act  only  as  a  cue  to  the  controller,  indicating  that 
an  extended  period  of  time  has  elapsed  since  the  message  was  sent. 
Because  of  this,  it  was  recommended  that  the  design  be  modified  to 
permit  the  controller  to  continue  to  wait  for  a  response,  if 
warranted  by  the  ATC  situation. 

Seven  of  the  eight  subjects  in  the  present  study  reported  that  this 
modification  was  acceptable.  The  remaining  subject  felt  that 
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controllers  would  not  require  a  special  indicator  to  signal 
extended  response  times. 

Because  the  function  of  the  timer  was  redefined  as  a  controller 
alert,  the  subjects  were  asked  to  consider  whether  requirements 
for  appropriate  expiration  times  should  be  changed.  Of  the  seven 
controllers  who  preferred  the  time  out  alert,  six  indicated  that 
intervals  shorter  than  the  nominal  40  seconds  tested  in  this  study 
might  be  preferred.  Subsequent  debriefing  discussions  resulted 
in  a  consensus  that  the  design  specification  should  require  an 
ability  to  adapt  the  expiration  time  by  facility.  In  addition,  the 
subjects  indicated  that,  within  a  facility,  it  should  be  possible 
to  vary  the  timeout  interval  by  service  type,  with  more  time- 
critical  classes  of  messages  having  shorter  alert  intervals. 

3. 1.1. 2  Transaction  Delete  Command. 

The  tested  design  permits  the  controller  to  delete  a  Data  Link 
transaction  that  is  in  progress,  a  transaction  that  has  received 
an  "unable"  response  from  the  pilot,  or  one  that  has  resulted  in 
a  technical  transmission  failure.  The  delete  action  clears  the 
data  block  and  status  list  displays  for  the  transaction  and  permits 
the  system  to  accept  the  next  message  to  the  aircraft. 

In  order  to  prevent  confusion  or  misunderstandings  that  could 
result  when  the  controller  makes  this  delete  input,  a  standard 
procedure  will  be  required  to  insure  that  the  aircrew  is  aware  that 
the  transaction  has  been  closed.  The  controllers  who  participated 
in  the  design  review  agreed  that  an  appropriate  procedure  would  be 
to  communicate  with  the  aircraft  by  voice  immediately  after  any 
delete  action.  To  deal  with  deleted  messages  that  may  not  have 
been  displayed  to  the  aircrew,  the  verbal  message  must  contain 
unambiguous  phraseology  that  clearly  identifies  the  specific 
message  to  be  disregarded.  In  the  situation  where  a  downlinked 
response  is  received  after  the  Data  Link  message  is  deleted  and 
verbal  coordination  has  been  initiated,  the  subjects  recommended 
that  the  response  be  recorded  by  the  system,  but  not  displayed  to 
the  controller. 

3. 1.1.3  Message  Resend  Command. 

The  third  general  system  design  issue  considered  in  this  study  was 
the  message  resend  command.  This  command  permits  a  controller  to 
rapidly  resend  a  message  that  presumably  had  failed  to  reach  the 
aircraft.  The  command  was  developed  to  simplify  the  task  of 
dealing  with  a  message  to  which  no  NAK  is  received,  either  because 
of  a  failure  of  the  system  to  send  the  message,  or  because  of 
message  corruption. 

The  resend  command  was  addressed  in  this  study  because  emerging 
information  about  the  architecture  of  the  communications  network 
that  is  being  developed  to  manage  Data  Link  functionality  indicates 
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that  the  resend  option  may  not  be  required.  In  the  Aeronautical 
Telecommunications  Network  (ATN) ,  failure  to  receive  a  technical 
acknowledgement  at  any  of  several  levels  of  the  system  will  cause 
the  system  to  automatically  resend  the  message  a  parameter  number 
of  times.  If  this  is  unsuccessful,  the  connection  between  the 
aircraft  and  the  controller  will  be  severed. 

In  response  to  this  design  information,  the  subject  controllers 
suggested  that  the  resend  would  not  be  useful  and  that  a  failure 
to  send  the  information  after  the  automatic  retry  sequence  should 
cause  a  unique  message  be  clearly  displayed  in  the  aircraft  data 
block  to  indicate  that  the  connection  has  been  severed  (e.g.,  "LINK 
FAIL") .  In  combination  with  the  loss  of  the  Data  Link 
equipage/eligibility  symbol,  such  a  display  would  signal  the 
controller  to  revert  to  voice  communication  with  the  aircraft  or 
to  initiate  actions  that  would  reestablish  the  Data  Link 
connection.  The  NAK  message  and  the  resend  option  should  be 
retained  only  if  a  message  transmission  failure  is  possible  prior 
to  the  point  where  the  message  has  passed  to  the  ATN,  and  there  is 
a  guarantee  that  it  could  not  have  reached  the  flight  deck. 

The  fact  that  several  technical  acknowledgements  will  be  generated 
within  the  ATN  also  led  the  controllers  to  question  the  meaning  of 
the  "delivered"  message  provided  in  the  status  displays.  While  it 
was  previously  assumed  that  this  message  would  indicate  only  that 
a  digital  check  on  the  integrity  of  the  message  had  been  performed 
by  the  initial  stage  of  the  airborne  receiver,  other  ATN  technical 
acknowledgements  could  imply  that  it  was  available  for  display  on 
the  flight  deck  instruments,  or  that  it  had  been  called  to  the 
display  device.  The  controllers  agreed  that,  other  than  a  pilot 
WILCO  or  UNABLE  response,  no  technical  acknowledgement  provides 
assurance  that  the  aircrew  has  read  the  message  or  is  considering 
a  response.  However,  they  also  felt  that  for  any  message  status 
display  to  be  of  value,  the  controller  will  require  clear  knowledge 
of  the  meaning  of  the  message  and  of  the  types  of  action  that  they 
will  be  able  to  initiate  to  bring  closure  to  the  transaction  in  a 
timely  manner.  If  the  status  message  is  ambiguous  or  if  no  usable 
information  is  provided  by  the  status  message,  the  subject 
controllers  indicated  that  the  message  should  not  be  displayed.  In 
general,  the  subjects  felt  that  end-to-end  simulation  will  be 
required  to  determine  whether  confusions  or  misinterpretations 
occur  when  the  "delivered"  message  means  that  the  message  is 
available  for  display  or  when  it  means  that  it  has  been  sent  to 
the  display  device.  While  all  current  transaction  state  displays 
should  be  retained  in  the  design  specification  for  the  present,  an 
ability  to  individually  suppress  these  status  messages  should  be 
included  pending  the  outcome  of  future  simulation  research. 

3. 1.1. 4  Global  Reset  of  Suppressed  Displays. 

As  the  human-computer  interface  for  the  terminal  Data  Link  services 
has  evolved,  requirements  for  informational  lists  and  menus  have 
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increased.  In  order  to  minimize  the  space  on  the  radar  display 
consumed  by  these  features  and  reduce  general  clutter,  options  have 
been  included  in  the  design  which  permit  the  controller  to  suppress 
and  retrieve  entire  lists  or  selected  components  of  the  displays. 
The  large  number  of  individual  retrieval  commands  unnecessarily 
complicates  the  task  of  resetting  the  system  to  a  nominal  state 
when  changing  controllers  at  a  position.  Because  of  this,  the 
subjects  in  the  current  study  recommended  the  addition  of  a  global 
reset  input  which  would  retrieve  all  suppressed  displays.  Affected 
displays  would  include  all  MT  and  TI  items,  the  TC  mode,  and  the 
status  list. 

3.1.2  Status  List  and  Data  Block  Transaction  Displays. 

Two  changes  to  the  status  list  and  data  block  displays  were 
introduced  for  this  study.  As  suggested  by  the  results  of  the 
second  Mini  Study,  the  message  content  of  a  MT  clearance  was 
indicated  using  a  shorthand  code  rather  than  the  item  number  from 
the  MT  list.  Thus,  for  example,  rather  than  displaying  "M2"  to 
indicate  that  message  number  two  had  been  sent,  the  shorthand 
"A120"  was  displayed  to  abbreviate  the  message  content  (Altitude 
12,000  feet).  The  design  retained  the  use  of  message  identifiers 
to  denote  the  content  of  TI  messages. 

The  second  modification  to  the  data  block  display  was  the  use  of 
single  letters  rather  than  three-letter  abbreviations  for  the 
transaction  status  indicators.  These  indicators  were  shortened  in 
the  data  block  in  order  to  provide  sufficient  space  on  the  third 
line  for  the  extended  message  content  data  described  above. 

All  eight  controllers  reported  that  they  preferred  the  shorthand 
content  display  over  the  previous  item  identifier  display.  Two 
controllers  indicated  that  the  identifier  display  should  be 
retained  as  an  option  adaptable  by  the  facility.  Explanations 
offered  by  the  subjects  regarding  their  preference  for  the 
shorthand  display  included  quicker  content  reference  without 
consulting  memory  or  the  MT  list,  improved  feedback  and  error 
detection  for  the  most  recent  clearance  sent,  and  improved  team 
coordination  and  communication  in  sectors  using  a  coordinator  or 
handoff  assistant. 

All  of  the  controllers  also  indicated  that  the  use  of  the  item 
identifier  for  the  TI  message  content  display  was  acceptable,  and 
that  the  use  of  an  asterisk  in  the  display  helped  to  signify  the 
message  type  (e.g.,  "T*A" ) . 

All  of  the  controllers  agreed  that  the  single  letter  status 
displays  in  the  data  block  would  be  acceptable.  However,  three 
controllers  noted  that  the  "failure"  status  types  (U,N,T)  should 
flash  at  a  different  rate  to  distinguish  the  event  from  a  handoff 
and  make  the  event  more  salient. 
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In  agreement  with  the  results  of  prior  studies,  a  majority  of  the 
controllers  indicated  that  they  do  not  use  the  status  list  to 
monitor  Data  Link  transactions.  However,  all  controllers  felt  that 
the  persistent  8-second  WILCO  display  would  be  useful  for 
individuals  who  choose  to  employ  this  display. 

3.1.3  History  List. 

Only  minor  changes  were  made  to  the  history  list  for  the  present 
study.  Based  on  past  results,  the  list  was  reduced  in  length  from 
the  last  five  messages  WILCOed  by  an  aircraft  to  the  last  three 
messages.  In  addition,  when  called  by  a  keyboard  command,  the 
history  list  appeared  in  the  status  list  position  rather  than  in 
the  TI  and  MT  list  position. 

All  eight  subjects  indicated  that  the  three  message  list  provided 
adequate  information  regarding  the  Data  Link  transaction  history 
of  an  aircraft.  However,  during  debriefing  discussions,  the 
subjects  agreed  that  design  specifications  should  permit  site 
adaptation  of  up  to  five  messages  in  order  to  accommodate 
unforeseen  field  requirements.  All  of  the  subjects  also  preferred 
the  status  list  position  for  the  history  list  over  the  MT  position. 
A  majority  of  the  controllers  felt  that  the  8-second  display  time 
for  the  history  list  would  be  sufficient  for  a  three-message  list. 
However,  the  subjects  also  felt  that  this  time  parameter  should  be 
adaptable  by  the  facility.  Additional  improvements  suggested  for 
this  feature  included  an  ability  to  examine  the  Data  Link  history 
of  an  aircraft  under  another  sector's  control,  and  requiring  the 
history  to  carry  over  across  sectors  within  a  facility.  Finally, 
a  "clear/enter"  keyboard  command  was  recommended  as  a  replacement 
for  the  "HL  slew"  input  to  cancel  the  list  prior  to  its  automatic 
removal . 

3.1.4  IC  Service. 

The  IC  service  was  modified  for  the  present  study  to  eliminate  the 
transaction  delay  produced  by  a  routine  requirement  to  initiate  the 
service  by  an  altitude  request  uplink.  In  the  tested  design,  the 
IC  message  was  downlinked  from  the  aircraft  by  appending  its 
assigned  altitude  to  the  pilot's  WILCO  response  to  the  preceding 
TC.  Altitude  requests  automatically  initiated  by  the  system  were 
used  to  elicit  the  IC  from  departing  aircraft  and  from  aircraft 
which  failed  to  append  the  message  to  the  TC  response. 

All  of  the  subjects  preferred  the  modified  service,  and  none 
foresaw  operational  problems  associated  with  the  new  procedure. 

3.1.5  TI  Service. 

The  tested  design  of  the  TI  service  was  modified  for  this  study  to 
increase  the  permissible  length  of  the  displayed  messages,  and 
provide  greater  flexibility  in  positioning  the  list  and  controlling 
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the  number  of  displayed  items.  All  subjects  felt  that  the  40 
character  line  length  was  acceptable.  However,  it  also  was  noted 
that,  because  of  the  broad  range  of  content  that  can  appear  in  a 
TI  message,  a  standard  abbreviation  dictionary  will  be  needed  for 
entering  these  messages  and  displaying  them  to  the  controller.  All 
controllers  also  preferred  the  change  from  numerals  to  alphabetic 
characters  as  item  identifiers  for  the  TI  messages.  This 
modification  was  introduced  to  reduce  the  occurrence  of  confusions 
among  TI  and  MT  item  selections. 

The  ability  to  position  and  suppress  or  retrieve  the  TI  list 
independently  of  the  MT  list  also  was  a  preferred  change.  In 
addition,  all  controllers  felt  that  the  ability  to  suppress 
individual  list  items  would  reduce  display  clutter  and  simplify 
item  selection. 

The  tested  design  permitted  the  combination  of  a  TI  message  with 
a  MT  message  in  a  single  uplink.  Five  of  the  subjects  indicated 
that  the  flexibility  to  combine  these  two  message  types  should  be 
increased.  During  debriefing,  all  subjects  agreed  that  it  will  be 
necessary  to  provide  controllers  with  the  ability  to  combine  more 
than  one  MT  clearance  with  a  TI  message.  Ideally,  it  should  be 
possible  to  send  a  TI  message  with  as  many  as  three  MT  messages 
(altitude,  heading,  and  speed) .  In  addition,  the  subjects 
suggested  that  it  should  be  possible  to  enter  and  send  the  combined 
TI  message  and  MT  clearance  in  any  order,  rather  than  requiring  the 
TI  message  to  precede  the  MT  message. 

Other  suggested  improvements  to  the  TI  service  were  oriented  toward 
simplifying  the  process  of  modifying  the  list.  These  included  the 
ability  to  selectively  edit  numeric  values  in  a  message,  and  a 
feature  which  would  automatically  change  the  full  list  to  conform 
to  a  change  in  runway  configuration. 

Finally,  one  subject  suggested  that  two  alternate  displays  of  the 
TI  list  items  be  made  available  to  the  controller.  One  of  these 
would  be  the  abbreviated  text  version  used  in  the  current  design. 
The  alternate  would  be  a  compressed  representation  containing  only 
key  information  from  the  message. 

3.1.6  TC  Service. 

Modifications  to  the  TC  service  introduced  for  this  study  included 
a  change  in  the  mode  display,  adding  the  ability  to  offer  a  sector 
handoff  when  a  Data  Link  transaction  is  in  progress,  and 
suppressing  the  receiving  sector’s  display  of  the  status  of  a  TC 
transaction. 

The  mode  display  provides  an  indication  of  whether  the  TC  will  be 
automatically  sent  or  held  for  manual  uplink  after  a  sector  handoff 
is  accepted.  All  of  the  subjects  preferred  the  placement  of  this 
display  in  the  System  Data  Area  (SDA)  over  its  former  position  in 
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the  first  line  of  the  status  list.  However,  the  controllers  also 
suggested  that  a  command  be  added  to  permit  suppression  of  the  mode 
display  when  not  required. 

All  subjects  also  expressed  satisfaction  with  the  added  ability  to 
offer  the  sector  handoff  while  a  transaction  is  in  progress.  This 
feature  presents  a  time  savings  because  it  does  not  force  the 
controller  to  wait  for  an  ongoing  transaction  to  be  WlLCOed  prior 
to  making  the  data  entries  which  complete  the  handoff  and 
automatically  prepare  the  transfer  message.  An  additional 
improvement  discussed  during  the  debriefing  and  recommended  for 
future  testing  was  the  addition  of  an  entry  which  would  further 
reduce  the  requirement  to  monitor  ATC  clearance  and  TC  messages 
spaced  closely  in  time.  In  this  proposal,  after  a  sector  handoff 
is  accepted  and  the  TC  message  is  available  for  manual  uplink,  the 
controller  would  have  the  option  to  enter  a  MT  clearance  followed 
by  an  "S'*.  This  additional  entry  would  automatically  send  the  TC 
immediately  after  the  pilot  WlLCOed  the  clearance  was  received. 

Mixed  responses  were  received  to  the  suppression  of  the  data  block 
display  of  a  TC  being  conducted  by  a  sending  sector.  While  six 
controllers  felt  the  display  increased  clutter,  two  subjects 
indicated  that  they  preferred  to  monitor  the  status  of  the 
transaction.  A  compromise  accepted  by  the  controllers  during  the 
debriefing  was  to  continue  to  suppress  the  display  of  this 
information,  but  to  add  an  input  (e.g. ,  ok)  that  would  permit  the 
controller  to  view  the  history  list,  status  list  and  data  block 
displays  of  individual  aircraft  at  other  sectors. 

3.1.7  MT  (Speed.  Heading.  Altitude  Clearances). 

The  results  of  Mini  Study  2  indicated  that,  under  high  workload 
conditions,  controllers  experienced  some  difficulty  in  using  the 
terminal  ATC  services  which  were  based  on  a  menu  interface.  As  a 
consequence,  a  number  of  design  changes  to  the  MT  and  TI  functions 
were  introduced  to  enhance  the  flexibility  of  the  system  and  to 
improve  the  speed  and  accuracy  with  which  controllers  were  able  to 
locate  and  send  menu  items. 

In  order  to  increase  the  utility  of  the  MT  service  while 
maintaining  reasonable  menu  length,  individual  menu  items  were 
redesigned  to  contain  "generic"  altitude,  heading,  and  velocity 
values.  When  selected  for  uplink,  the  direction  of  an  altitude 
change  (climb/descend)  or  of  a  velocity  change  (increase/decrease) 
was  added  to  the  message  by  system  automation.  For  heading 
changes,  the  controller  could  precede  the  menu  item  number  entry 
by  "L"  or  "R"  to  include  the  direction  of  the  turn  in  the  uplinked 
message.  Each  of  these  modifications  effectively  doubled  the 
number  of  available  menu  messages  without  increasing  the  number  of 
displayed  menu  items. 
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All  of  the  subject  controllers  favored  the  generic  message 
structure  for  the  MT  items  over  the  earlier  design  in  which  each 
item  represented  a  single  clearance. 

The  following  are  design  features  of  the  MT  and,  in  some  cases,  the 
TI  service  human-computer  interface  that  were  introduced  for  this 
study  with  the  intent  of  reducing  error  and  simplifying  the  task 
of  uplinking  messages: 

a.  To  reduce  inadvertent  selection  of  items  from  the 
unintended  list,  letters  were  used  as  item  identifiers  for  TI 
messages  and  numbers  for  MT  messages. 

b.  Headers  (HDG,  ALT,  VEL,  MULT)  were  used  between  groups  of 
menu  items  to  assist  in  the  task  of  locating  desired  messages  in 
the  MT  list. 


c.  Unused  menu  items  could  be  individually  suppressed  to 
reduce  list  length  and  display  clutter. 

d.  The  full  MT  list  or  TI  list  could  be  suppressed  to  reduce 
display  clutter. 


e.  The  MT  and  TI  lists  could  be  independently  positioned  on 
the  radar  display  to  minimize  visual  scanning  requirements. 

f.  The  key  entries  used  to  prefix  menu  by-pass  (manually 
entered)  clearances  (H,A,V)  were  selected  because  they  appear  in 
a  single  column  on  the  ARTS  keyboard  and  in  the  same  order  as  they 
appear  in  the  MT  list. 


During  the  design  review,  the  subjects  were  asked  to  evaluate  the 
effectiveness  of  each  of  these  design  features  on  a  7-point  scale 
with  a  center  point  of  0  "no  effect  on  errors  or  performance,"  and 
ranging  from  +3  "very  positive  effect"  to  -3  "very  negative 
effect."  Ratings  received  by  each  of  the  design  features  are 
presented  below: 


Design 

Feature 


Controller  Subject  No. 
12345678 


Median 

Rating 


a.  13 

b.  3  3 

c.  13 

d.  11 

e.  3  3 

f .  3  1 


3  3  2  2 

2  3  12 

0  3  2  3 

2  3  3  2 

3  3  3  2 

2  3  2  2 


3  3  3.0 

3  2  2.5 

3  2  2.5 

3  2  2.0 

3  1  3.0 

3  0  2.0 


As  shown  above,  none  of  the  design  features  added  to  the  menu- 
oriented  TI  and  MT  services  received  negative  effect  ratings  from 
any  of  the  subjects.  While  the  use  of  differentiated  item 
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identification  numbers,  and  the  ability  to  independently  position 
the  two  menus  (features  1  and  5)  received  the  highest  median 
ratings,  a  non-parametric  analysis  of  variance  indicated  that  the 
six  features  were  not  significantly  different  in  terms  of  their 
overall  positive  benefits  (Chi2  =  1.929,  p-.85).  Inspection  of  the 
data  suggests  that  the  failure  of  any  subset  of  features  to  emerge 
as  more  highly  beneficial  than  the  others  was  a  result  of  a  high 
level  of  intersubject  variability.  While  nearly  all  subjects 
predicted  some  positive  performance  impact  of  all  features, 
individual  subject's  judgments  of  the  magnitude  of  the  benefit 
ranged  from  modest  to  high  in  every  case. 

3.1.8  Content  and  Application  of  the  MT  and  TI  Lists. 

Over  the  course  of  development  of  the  MT  and  TI  services,  a  variety 
of  modifications  have  been  made  to  these  menu-based  services  to 
improve  their  operational  suitability  and  usaoility  by  controllers. 
As  a  part  of  the  design  review,  the  subjects  were  asked  to  evaluate 
whether  the  MT  menu  provided  sufficient  flexibility  to  meet  field 
requirements  and  to  express  their  opinions  regarding  the  assignment 
of  message  types  to  the  TI  and  MT  lists. 

As  designed  for  the  initial  terminal  ATC  services,  the  MT  list  is 
a  completely  structured  menu.  Individual  lines  are  assigned  to 
specific  clearance  types  and  the  content  of  each  line  is  highly 
standardized.  This  design  approach  permits  extensive  use  of 
automation  vO  construct  the  uplinked  message  and  provides  for  more 
efficient  coding  of  the  clearance  for  digital  transmission  than  a 
free  text  message.  The  limitation  of  the  structured  menu  design 
is  that  it  may  offer  insufficient  flexibility  to  represent  the  full 
range  of  clearance  messages  that  the  controller  may  wish  to  send. 
During  development,  the  following  features  were  progressively  added 
to  the  design  in  order  to  increase  menu  flexibility: 

a.  Menu  items  dedicated  to  speed,  heading,  and  altitude 
clearances  with  the  ability  to  change  individual  numeric  values  on 
line. 


b.  Capability  to  combine  individual  speed,  heading,  and 
altitude  menu  items  in  a  single  uplink. 

c.  Capability  to  create  a  special  multiple  clearance  line  in 
addition  to  the  individual  speed,  heading,  and  altitude  items. 

d.  A  menu  bypass  feature  for  composing  clearances  not 
contained  in  the  menu. 

e.  Generic  clearance  messages  with  automatic  determination  of 
climb/descend  and  increase/decrease,  plus  the  ability  to  control 
turn  direction. 
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f.  Capability  to  combine  a  TI  and  a  MT  item  in  a  single 
message. 

The  controllers  were  polled  to  determine  whether  the  existing  MT 
design  with  these  features  would  be  sufficient  for  generating  the 
clearance  messages  that  will  be  needed  in  the  operational  terminal 
ATC  environment.  All  eight  controllers  indicated  that  the  design 
appeared  to  be  sufficient,  and  that  the  use  of  an  unstructured, 
free  text  approach  to  the  MT  service  would  not  be  required. 
However,  in  discussions  following  the  full  scale  simulation  phase 
of  the  study,  the  controllers  agreed  that  maximal  efficiency  of  the 
structured  menu  would  be  achieved  by  removing  the  current 
limitations  on  the  number  of  messages  that  could  be  created  in  each 
clearance  category.  That  is,  within  the  limits  of  total  menu 
length  (e.g.,  nine  items),  it  should  be  possible  to  have  more  than 
one  combined  clearance  line,  and  as  many  speed,  heading,  and 
altitude  lines  as  required  by  the  control  sector. 

The  issue  of  differential  assignment  of  messages  to  the  MT  and  TI 
lists  is  one  which  has  been  reconsidered  several  times  during  the 
development  process.  In  the  original  configuration,  the  TI  menu 
was  restricted  to  the  informational  messages  that  are  sent  to 
aircraft  as  they  enter  some  control  sectors,  while  the  MT  menu  was 
used  for  all  control  clearances.  As  a  result  of  extensive  testing 
during  full  scale  simulation  in  the  second  Mini  Study,  the 
application  of  the  TI  menu  was  extended  to  include  clearances 
commonly  sent  in  conjunction  with  these  informational  messages, 
and  to  other  messages  not  suited  to  the  structured  MT  list  design. 
Debriefings  following  that  study  suggested  that  this  extended 
application  could  reduce  the  functional  distinctiveness  of  the  two 
menu  lists  and  create  difficulties  in  locating  and  selecting 
desired  items  for  uplink. 

This  issue  was  revisited  following  the  extended  simulation  trials 
of  the  present  study.  The  consensus  among  the  controllers  was  that 
the  TI  menu  should  not  be  arbitrarily  restricted  to  purely 
informational  messages.  Any  benefits  of  such  a  restriction  were 
seen  as  being  outweighed  by  the  ability  to  efficiently  combine 
logically  related  message  elements.  In  the  redefined  logic  for 
message  assignment,  it  was  agreed  that  the  MT  list  will  continue 
to  be  used  for  structured  clearances  as  described  above.  The  TI 
menu  will  contain  lengthy,  repetitively  used,  text-oriented 
messages,  including  an  associated  clearance  when  required.  The 
subjects  indicated  that  these  messages  will  encompass  those 
typically  considered  to  be  the  first  and  last  messages  sent  by  a 
terminal  controller  depending  upon  the  sector  entry  point  of  an 
aircraft  or  its  destination. 
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3.1.9  Input  Error  Prevention  and  Situation  Awareness. 


The  final  topics  considered  during  design  review  debriefing  were 
keyboard  entry  errors  and  the  impact  of  Data  Link  entries  on  the 
controller's  awareness  of  prior  messages  sent  to  an  aircraft. 

The  terminal  Data  Link  initial  service  designs  make  exclusive  use 
of  keyboard  entries  to  select  messages  for  uplink  from  menus  and 
to  compose  messages  in  a  shorthand  form.  In  the  current  design, 
potential  data  entry  error  was  taken  into  consideration  by 
differentiating  item  identifiers  in  the  two  menu  lists. 
Additionally,  shorthand  abbreviations  of  sent  messages  were  added 
to  the  status  list  and  data  block  to  enhance  self  detection  of 
errors. 

While  quantitative  data  have  not  yet  been  collected  to  determine 
actual  Data  Link  input  error  rates,  the  subjective  response  of 
test  controllers  indicates  that  significant  error  potential  may 
exist  when  entering  clearances  using  the  menu  bypass  function.  The 
subjects  agreed  that  removing  the  bypass  function  from  the  design 
to  prevent  error  is  an  unacceptable  solution  which  would 
significantly  decrease  required  flexibility  in  the  system. 
Alternatives  that  were  considered  included  the  use  of  unique  two- 
letter  abbreviations  rather  than  single  letters  when  defining  the 
clearance  type,  employing  different  numbers  of  digits  to  specify 
the  numeric  value  for  each  clearance  type,  and  automatic  computer 
checks  on  the  reasonableness  of  the  clearance  entered  for  uplink. 

Because  each  of  these  alternatives  could  adversely  impact 
controller  workload  or  software  complexity,  it  was  determined  that 
research  should  be  conducted  to  determine  the  actual  nature  of 
errors  made  in  both  voice  messages  and  Data  Link  entries,  and  to 
assess  their  comparative  rates  of  occurrence.  This  research  must 
examine  both  controller  detected  and  undetected  errors  in  menu 
selections  and  by-pass  composition.  In  addition,  the  research 
should  address  any  potential  for  error  in  calling  implied  functions 
elicited  by  track  ball  entries  and  keystrokes  which,  if  entered  at 
inappropriate  times,  could  initiate  unintended  actions. 

Controller  memory  for  messages  sent  by  Data  Link  also  was  discussed 
during  the  debriefing.  Anecdotal  accounts  of  forgetting  whether 
an  intended  message  actually  had  been  sent  to  an  aircraft  and  of 
failing  to  remember  the  content  of  a  message  known  to  have  been 
sent  v/ere  discussed  during  prior  mini  studies.  In  the  current 
study  this  issue  was  reconsidered,  and  the  subjects  agreed  that 
although  the  history  list  acts  as  an  aid  to  memory,  failure  to 
remember  messages  could  affect  the  quality  of  the  controller's 
situation  awareness,  or  the  workload  associated  with  maintaining 
required  situation  awareness.  It  was  decided  that  future  research 
should  be  conducted  to  determine  whether  short  term  memory  for 
voiced  and  manually  entered  ATC  messages  differs.  This  research 
also  should  examine  the  hypothesis  that  bypass  messages  which 
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articulate  the  intended  message  may  produce  better  memory  than 
clearances  selected  from  a  menu  list. 

3.2  FULL  SCALE  SIMULATION. 

3.2.1  Strategy  Analysis. 

3.2. 1.1  Strategy  Questionnaires. 

The  results  of  the  questionnaires  distributed  between  test  runs 
indicated  that  when  controllers  worked  individually,  normal 
(current)  operational  procedures  were  implemented  in  voice-only 
runs.  When  Data  Link  was  available,  two  controllers  initially  used 
all  Data  Link,  but,  as  traffic  load  increased,  called  for  an 
assistant  who  took  on  Data  Link  for  TI  and  IC  messages  while  the 
primary  controller  used  voice.  Other  controllers  applied  the 
strategy  of  using  all  voice  on  final  approaches  and  Data  Link  for 
initial  messages. 

Controllers  varied  from  using  Data  Link  for  TI  messages  only  to 
using  it  for  TI  messages,  initial  vectors,  expected  approaches, 
headings,  altitudes,  and  speeds.  Controllers  who  used  Data  Link 
more  often  reported  switching  to  voice  in  some  cases  due  to  pilot 
errors.  In  all  cases,  Data  Link  was  usee  much  less  often  for  turns 
onto  final  approaches.  When  traffic  was  heavy,  strategies  included 
going  to  voice  for  clearances  farther  out  from  final,  using  reduced 
speeds,  and  asking  an  assistant  for  help. 

All  controllers  reported  using  the  TI  list  in  all  cases.  All  six 
reported  using  MT  clearances.  Five  said  they  bypassed  the  menu  as 
they  got  closer  to  the  airport  and  when  busy.  The  sixth  controller 
said  he  went  to  voice  under  such  conditions.  It  appeared  that  for 
some  controllers  there  was  a  progression  from  MT  to  the  bypass 
function  to  voice  as  aircraft  got  closer  in  and  as  controllers 
became  busier. 

When  two  controllers  worked  voice-only  as  a  team,  two  basic 
strategies  were  used.  Two  teams  indicated  that  the  assistant 
controller  performed  no  function.  The  remaining  four  teams  said 
that  the  assistant  took  on  duties  typically  handled  by  a  second 
person  assigned  to  a  sector  in  the  field.  These  included  taking 
sector  handoffs,  performing  this  task  plus  acting  as  a  monitor 
providing  a  second  pair  of  eyes,  and  moving  data  blocks  after  the 
approach  clearance  was  given.  None  reported  sharing  the  radio. 
In  general,  voice-only  strategies  appeared  to  be  identical  in  the 
one  and  two  controller  conditions.  With  two  controllers,  the 
second  person  either  acted  as  a  relatively  passive  observer  or  took 
on  normal  duties  of  a  handoff  man. 

In  the  Data  Link  team  situation,  all  controllers  reported  extensive 
use  of  Data  Link.  This  ranged  from  using  only  TI,  initial  speeds, 
and  headings  to  using  Data  Link  for  all  functions.  Those  who 
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adopted  the  second  strategy  noted  that  most  use  of  voice  was  done 
to  compensate  for  some  simulation  pilots'  inability  to  deal  with 
large  numbers  of  multi-element  Data  Link  clearances.  It  should  be 
noted  that  these  problems  experienced  by  the  simulation  pilots  were 
attributable  to  message  display  methods  and  procedures  used  in  the 
NSSF  rather  than  to  limitations  that  would  be  experienced  by  actual 
pilots  in  an  operational  setting. 

Three  basic  strategies  for  dividing  duties  were  adopted  by  the 
teams.  None  of  the  teams  reported  sharing  the  radio  frequency. 
In  every  case,  the  radar  controller  used  voice  while  the  assistant 
used  Data  Link.  The  strategies  differed  in  the  extent  to  which  the 
primary  controller  used  Data  Link  in  addition  to  voice,  and  in  the 
manner  in  which  communications  duties  were  divided  between  the  team 
members. 

Strategy  A:  (Two  teams)  Highly  defined  duties  and  control  area, 

Data  link  not  used  by  primary  controller. 

Controller:  Voice-only,  handled  turns  to  final  and  approach 

clearance,  dealt  with  non-Data  Link  arriving 
aircraft  on  request  from  assistant. 

Assistant:  Data  Link  only,  used  TI  and  MT  list  on  outer  fixes 

and  gave  initial  headings  and  altitudes.  One  team 
also  monitored  controller's  load  on  final  and  used 
Data  Link  to  reduce  speeds. 

Strategy  B:  (Three  teams)  Defined  duties,  extensive  use  of  Data 

Link  by  both. 

Controller:  Used  Data  Link  and  voice.  Gave  final  turns  and 

approach  clearances  by  Data  Link  as  much  as 
possible,  used  voice  for  arrivals  on  request. 

Assistant:  Used  Data  Link,  handled  TI  and  used  MT  for 

clearances,  and  any  others  on  request. 

Strategy  C:  (One  team)  Fully  integrated,  no  set  duties,  high 

level  of  coordination  required,  both  used  Data  Link. 

Controller:  Shared  sequencing  decisions  and  clearances. 

Assistant:  Repositioned  data  blocks  on  final,  shared  sequencing 

decisions  and  clearances. 

The  controllers  reported  several  approaches  to  dealing  with  heavy 
traffic  volume.  One  team  indicated  that  they  made  no  changes  to 
their  approach.  Two  teams  reported  that  as  simulation  pilots  fell 
behind,  using  Data  Link  became  more  difficult  and  resulted  in  an 
increase  in  voice  usage.  Two  teams  reported  sending  speed  and 
heading  changes  earlier,  and  increasing  speed  control.  Finally, 


one  team  reported  that  the  assistant  used  combined  TI  and  MT 
messages  to  position  arriving  aircraft  more  efficiently  while  the 
primary  controller  went  to  voice. 

Several  controller  teams  reported  modifications  to  the  TI  and  MT 
lists.  It  appeared  they  did  this  more  in  the  individual  controller 
condition  to  better  deal  with  the  traffic.  Three  teams  reported 
developing  a  TI  message  which  contained  multiple  elements  including 
altitudes  and  approach  clearances.  This  effectively  reduced  the 
number  of  messages  sent.  One  team  changed  a  heading  value  in  TI, 
another  suppressed  a  message.  In  MT,  two  teams  made  a  new  multiple 
clearance  and  one  modified  a  heading.  All  teams  used  MT.  Bypass 
was  used  extensively  by  teams  in  which  primary  controller  used  Data 
Link,  especially  as  traffic  increased  and  when  using  Data  Link  for 
vectors  to  final. 

3. 2. 1.2  Individual  Strategy  Debriefings. 

The  results  of  the  initial  debriefing  questions  at  the  end  of  the 
full  scale  simulation  indicated  that  when  working  individually, 
two  of  the  eight  controllers  reported  using  Data  Link  almost 
exclusively,  and  noted  that  they  compensated  for  Data  Link  delays 
by  sending  messages  earlier  with  Data  Link.  The  other  controllers 
reported  using  voice  for  critical  situations,  "fine-tuned" 
clearances,  inner  fixes,  and  finals,  whereas  they  used  Data  Link 
on  outer  fixes  and  departures.  Aircraft  were  slowed  sooner  because 
of  Data  Link  communication  delays,  and  the  bypass  function  and 
voice  were  used  as  traffic  increased. 

When  the  controllers  were  asked  to  choose  which  communication 
condition  was  more  effective  when  working  individually  (voice-only 
or  Data  Link)  four  elected  voice-only.  Their  reasons  included  not 
having  to  worry  about  delays,  not  being  distracted  with  new  working 
tools,  being  able  to  concentrate  on  traffic  and  not  the  keyboard, 
and  being  able  to  make  tighter  finals.  Additional  comments  about 
Data  Link  included  unfamiliarity  with  the  menu,  heavy  workload,  and 
increased  workload  for  tactical  commands.  Two  controllers  said 
that  Data  Link  was  the  more  effective  medium  when  working  alone. 
One  controller  found  neither  strategy  to  be  more  effective  than  the 
other,  and  one  controller's  response  was  unclear. 

In  the  voice-only  team  conditions,  all  teams  used  normal  voice 
procedures.  As  in  the  between  run  interviews,  two  teams  reported 
that  the  assistant  controller  was  not  used  at  all;  no  team  work. 
Two  teams  reported  that  the  second  controller  was  an  additional 
set  of  eyes,  but  was  basically  ineffective.  Three  teams  reported 
that  the  primary  controller  did  all  the  voice  and  the  second 
controller  only  took  handoffs.  Only  one  team  used  the  second 
controller  to  keep  the  data  blocks  straight  in  addition  to  taking 
handoffs.  None  of  the  teams  reported  sharing  the  radio. 
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Different  strategies  were  applied  when  using  Data  Link  as  opposed 
to  voice-only  when  controllers  worked  in  a  team.  All  controllers 
reported  extensive  use  of  Data  Link,  specifically  for  TI,  altitude 
assignment,  heading  changes,  and  speed  changes.  All  controllers 
reported  they  would  switch  to  voice  for  conflict  resolution  and  to 
deal  with  missed  approaches,  but  would  switch  back  to  Data  Link 
after  a  conflict  was  resolved. 

All  of  the  controllers  reported  sharing  duties  when  using  Data 
Link.  In  some  situations,  one  controller  was  basically  in  command 
and  did  most  of  the  work  until  the  workload  became  heavy,  then 
teamwork  was  necessary.  One  controller  usually  gave  clearances  and 
took  handoffs,  but  in  some  runs,  both  controllers  issued 
clearances. 

When  the  controllers  were  asked  to  choose  the  more  effective  team 
strategy,  voice-only  or  Data  Link,  six  out  of  eight  controllers 
elected  Data  Link.  They  indicated  that  the  second  controller  made 
a  difference,  preliminary  instructions  could  be  given,  and  two 
modes  of  communication  were  very  effective.  One  controller, 
however,  indicated  that  with  Data  Link,  ?nore  simulation  pilot 
errors  occurred,  and  another  controller  mentioned  that  although 
Data  Link  was  very  effective,  voice  was  still  used  on  final. 
Another  controller  mentioned  that  more  experience  was  needed  with 
Data  Link.  The  remaining  two  controllers  chose  voice-only  as  the 
more  effective  strategy  because  Data  Link  required  too  much 
coordination  between  controllers,  was  less  efficient,  and  did  not 
allow  for  optimal  spacing  during  finals. 

The  controllers  were  also  asked  to  recall  a  specific  critical 
situation  they  encountered  during  the  simulation  runs  and  to 
indicate  whether  they  used  Data  Link  or  voice-only  to  deal  with 
the  situation  and  why.  It  was  found  that  voice  was  used  more  often 
to  communicate  with  a  departing  aircraft,  for  final  clearances,  and 
to  resolve  conflicts  because  of  the  instant  communication  to  and 
the  immediate  response  from  the  pilot.  Data  Link  was  used  "when 
there  was  time  to  use  it."  The  controllers  on  one  team  reported 
using  Data  Link,  but  only  because  time  was  not  a  critical  factor. 
If  time  had  been  a  critical  factor,  they  would  have  resorted  to 
voice.  One  controller  added  an  additional  comment  that  simulator 
pilots  had  a  hard  time  keeping  up  with  traffic,  and  another 
controller  said  the  pilot  kept  up  with  the  controller  when  Data 
Link  was  used,  but  fell  behind  when  the  controller  switched  to 
voice. 

3. 2. 1.3  Group  Discussion  of  Strategies. 

Debriefing  sessions  were  conducted  following  the  test  runs.  Their 
purpose  was  to  reexamine  the  Data  Link  service  designs  in  light  of 
the  subjects'  experiences  with  Data  Link.  Other  discussion  topics 
included  global  design  philosophy  issues,  strategies  for  combining 
voice  and  Data  Link,  potential  opportunities  for  controller  error 
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in  using  Data  Link,  and  the  overall  projected  effects  of  Data  Link 
on  ATC. 

Subjects  were  asked  whether  they  found  the  individual  or  team 
strategy  more  effective  when  using  the  Data  Link.  The  team  concept 
was  agreed  to  be  highly  effective,  since  it  allowed  for  both 
controllers  to  issue  instructions  to  many  aircraft  at  the  same 
time.  If  one  controller  handled  voice-only,  he  could  take  care  of 
situations  needing  immediate  attention,  such  as  missed  approaches, 
missed  turns,  missed  altitudes,  or  missed  instructions  of  any  sort, 
while  the  second  controller  could  issue  instructions  to  other 
aircraft  with  Data  Link  to  maintain  a  safe  situation.  In 
voice-only  scenarios,  the  teammate  contributed  little  or  nothing. 
Data  Link,  on  the  other  hand,  was  a  cooperative  effort,  usually 
with  one  controller  considered  to  be  in  command. 

As  one  controller  commented,  when  a  critical  situation  arose  while 
he  was  working  individually  with  Data  Link  or  voice,  he  caused 
delays  by  spinning  aircraft  on  the  outer  fixes  so  that  he  could 
focus  on  the  immediate  situation.  With  Data  Link  and  a  second 
controller,  however,  all  the  initial  work  was  done  for  him  and, 
thus,  the  flow  of  traffic  continued  to  run  smoothly.  Data  Link, 
in  a  sense,  allowed  for  two  frequencies.  when  asked  whether 
working  with  Data  Link  in  busy  situations  made  any  difference,  one 
controller  explained  that  the  mental  picture  he  formed  by 
constantly  scanning  the  screen  was  disrupted  by  having  to  look  down 
at  the  keyboard.  He  reported  a  loss  of  concentration  with  Data 
Link.  Other  controllers  commented  on  the  unfamiliarity  with  Data 
Link. 

The  general  consensus  gathered  from  the  debriefing  sessions  was 
that  with  combined  sectors,  it  was  easier  to  handle  traffic  with 
Data  Link  when  one  person  handled  voice,  and  the  other  person 
handled  Data  Link.  It  was  agreed  that  it  is  always  beneficial  to 
have  a  second  set  of  eyes.  A  problem  pointed  out  by  one 
controller,  however,  was  most  of  the  controllers  had  not  worked 
together  before  this  test  and,  therefore,  were  not  familiar  with 
each  other's  habits.  The  controllers  felt  that  their  performances 
were  more  efficient  the  second  time  they  worked  together,  and  the 
experiment  probably  did  not  reflect  what  could  have  been  done  by 
a  crew  who  worked  together  on  a  regular  basis. 

The  effectiveness  of  Data  Link,  in  general,  in  the  terminal 
environment  was  also  discussed  in  the  debriefing  sessions.  One 
controller  commented  on  Data  Link  as  beneficial  in  certain  special 
situations,  such  as  with  an  emergency  aircraft  requiring  continuous 
instructions  or  a  stuck  microphone  blocking  a  voice  frequency,  but 
no  more  effective  than  voice  in  normal  traffic  flow.  Anothei 
controller  considered  Data  Link  to  be  effective  in  heavy  volume 
situations,  especially  on  departures,  where  more  aircraft  could  be 
controlled. 
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Most  of  the  controllers  interviewed  said  they  would  not  use  Data 
Link  for  finals  because  much  more  attention  must  be  given  to  the 
aircraft  that  is  making  the  final  approach.  It  was  distracting  to 
have  to  look  down  at  the  history  list  to  make  sure  the  message  was 
sent  to  the  Data  Link  target.  One  controller  reported  feeling  more 
pressure  working  departures  using  Data  Link  because  it  involved  too 
much  preliminary  thinking  about  what  message  to  send,  as  opposed 
to  simply  having  to  speak  what  was  on  his  mind. 

As  noted  in  the  design  review  results,  the  relationship  between 
short  term  memory  and  Data  Link  was  also  discussed  during  the 
sessions.  One  controller  mentioned  that  when  using  Data  Link,  he 
would  often  have  to  go  back  to  the  history  list  to  make  sure  an 
instruction  had  been  sent.  In  one  instance  he  found  that  he  had 
typed  the  same  message  twice  with  Data  Link.  Memory  for  voice 
instructions,  on  the  other  hand,  was  not  a  problem.  Other 
controllers  agreed  that  it  was  usually  easier  to  catch  a  voice 
error  as  opposed  to  a  Data  Link  keyboard  error. 

3. 2. 1.4  Discussion  of  Strategy  Results. 

The  availability  of  Data  Link  in  addition  to  voice  communications 
makes  possible  the  development  of  new  strategies  for  the  control 
of  aircraft  in  the  terminal  environment.  In  Mini  Study  3,  the 
provision  of  a  team  condition  where  controllers  could  exercise  Data 
Link  made  further  new  strategies  possible.  As  discussed  in  the 
above  sections,  various  attempts  were  made  to  record  and  evaluate 
the  approaches  developed  by  study  participants.  In  this  section, 
the  potentially  useful  strategies  used  and  suggested  by  the 
controllers  are  summarized. 

In  general,  Data  Link  was  agreed  to  be  a  suitable  mode  of 
communication  for  MT  clearances  (altitude  assignments,  heading 
changes,  and  speed  changes)  and  for  TI  messages,  but  not  for 
instructions  requiring  precise  timing,  conflict  resolutions,  or 
the  handling  of  missed  approaches.  Strategies  included  sending 
messages  earlier  to  compensate  for  the  Data  Link  delays  and 
bypassing  menus  in  heavy  traffic  conditions.  Controllers  switched 
to  voice  in  situations  where  time  was  a  critical  factor,  such  as 
vectoring  aircraft  to  inner  fixes  and  finals  or  after  pilot  errors 
occurred.  Half  of  the  controllers  said  they  preferred  voice  over 
Data  Link  when  working  alone. 

Under  the  team  condition,  strategies  were  more  varied,  but  all 
controllers  reported  extensive  use  of  Data  Link.  In  most 
situations,  one  controller  was  considered  to  be  the  primary 
controller  who  always  used  voice,  but  may  or  may  not  have  used  Data 
Link.  He  usually  handled  turns  to  finals  and  approach  clearances. 
The  secondary  controller  always  used  Data  Link,  but  may  or  may  not 
have  used  voice.  He  generally  used  TI  and  MT  lists  for  outer  fixes 
and  clearances,  took  handoffs,  gave  preliminary  instructions,  and. 
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in  some  cases,  repositioned  data  blocks.  None  of  the  teams  shared 
the  radio  frequency. 

3. 2. 1.5  Projected  Effects  of  Controller  Team  Size. 

The  final  technique  that  was  used  to  explore  controller  strategies 
and  their  perceived  effectiveness  was  a  post-test  comparison  of  the 
four  test  conditions  on  the  dimensions  of  individual  controller 
workload,  system  capacity,  and  safety. 

The  data  obtained  from  each  subject  were  transformed  to  produce 
relative  values  on  a  normalized  ratio  scale  for  each  of  the  four 
conditions  using  a  version  of  the  AHP.  The  AHP  uses  data  obtained 
from  sets  of  relative  judgments  rather  than  independent  absolute 
judgments  to  quantify  subjective  data.  Each  item  to  be  evaluated 
is  compared  with  all  other  items  and  the  data  are  represented  in 
a  judgment  matrix  in  which  each  row  or  column  reflects  one  item's 
dominance  relative  to  all  other  items.  The  geometric  means  method 
is  used  to  calculate  the  scale  values  which  represent  the  position 
of  the  item  on  a  scale  relative  to  all  other  items  in  the 
comparison.  In  the  following  analyses,  the  means  of  the  eight 
subject's  values  on  the  AHP  scale  were  compared  for  each 
combination  of  communication  condition  and  number  of  controllers 
at  the  sector.  The  statistical  significance  of  the  relative 
differences  among  the  conditions  was  tested  for  individual 
controller  workload,  capacity,  and  safety. 

Statistical  analysis  of  the  AHP  scale  workload  means  indicated  that 
the  perceived  level  of  individual  controller  workload  was  not 
significantly  affected  by  the  communication  condition,  F(l,  7)  = 
.04,  p  -  .83,  or  the  number  of  controllers  at  the  sector,  F(l,  7) 
=  4.06,  p  =  .08.  In  addition,  no  statistically  significant 
interaction  between  communication  condition  and  number  of 
controllers  was  detected,  F(l,  7)  =  1.61,  p  =  .24. 

These  findings  are  consistent  with  a  majority  of  the  design 
development  studies  that  have  been  conducted  with  Data  Link 
controllers  which  show  either  no  effect  of  Data  Link  on  perceived 
workload,  or  a  mild  reduction  in  comparison  to  voice-only 
conditions.  Variations  in  controller  workload  associated  with 
voice  and  Data  Link  comparisons  in  different  studies  appear  to  be 
closely  linked  to  the  difficulty  of  the  ATC  problem,  the  degree  to 
which  the  ATC  problem  is  structured  to  take  advantage  of  Data 
Link's  ability  to  simplify  the  issuance  of  routine  messages,  and 
training  level  on  the  use  of  Data  Link. 

In  contrast  to  the  workload  data,  the  capacity  dimension  subject 
ratings  were  significantly  affected  by  the  number  of  controllers 
at  the  sector.  While  the  overall  difference  between  communication 
conditions  was  not  significant,  F(l,  7)  =  1.09,  p  =  .32,  two 
controllers  were  judged  as  being  capable  of  producing  higher 
overall  capacity  of  the  ATC  system  than  one  controller  at  the 


38 


combined  sector,  F(l,  7)  =  6.77,  p  =  .03.  However, 
the  interaction  between  communication  condition  and  number  of 
controllers  also  was  significant,  F(l,  7)  =  8.40,  p  =  .02. 

As  suggested  by  figure  3,  and  confirmed  by  planned  comparison 
analysis  of  the  interaction  means,  this  finding  indicates  that 
controllers  felt  that  the  two-controller  team  was  capable  of 
increasing  capacity,  but  only  when  the  voice  system  was 
supplemented  by  Data  Link. 

Controller  comments  recorded  on  the  rating  sheets  and  during 
debriefings  were  consistent  with  this  interpretation.  Several 
subjects  noted  that  capacity  is  ultimately  determined  by  the 
acceptance  rate  at  the  airport.  However,  it  also  was  stated  that 
Data  Link  has  the  potential  to  increase  capacity  in  some  conditions 
with  two  controllers  because  it  will  provide  a  second  communication 
channel  that  could  be  used  by  an  assistant  controller  to  handle 
routine  duties  (e.g.,  TC,  TI  service).  Thus,  the  primary 
controller  may  have  an  improved  capability  to  produce  small 
capacity  increases  by  preventing  gaps  in  the  arrival  stream.  Other 
comments  suggested  that  the  second  controller  also  may  be  able  to 
increase  capacity  by  using  Data  Link  to  maintain  traffic  flow  when 
the  primary  controller  is  required  to  devote  complete  attention  to 
resolving  a  separation  problem  or  pilot  error  occurring  on  the 
final  approach. 

The  results  on  the  ATC  safety  dimension  showed  that  Data  Link  was 
perceived  as  producing  higher  system  safety  than  voice-only 
communications,  ?(1,  7)  =  8.14,  p  =  .02  (see  figure  4).  While  no 
significant  difference  was  detected  between  the  one-  and  two- 
controller  conditions  (p  =  .053),  analysis  of  the  significant 
interaction  F(l,  7)  =  15.97,  p  =  .005  suggests  that  the  effect  of 
Data  Link  on  safety  was  largely  confined  to  the  situations  in  which 
two  controllers  were  at  the  sector. 

These  data  also  are  consistent  with  subject  opinions  recorded  on 
the  questionnaire.  While  two  controllers  at  a  voice  sector  cannot 
improve  communications  on  a  single  channel,  it  was  noted  that  some 
improvement  in  safety  might  have  been  realized  by  the  "extra  pair 
of  eyes."  However,  with  Data  Link,  the  second  controller  provided 
this  monitoring  function  in  addition  to  offloading  routine 
communications  from  the  primary  controller.  Furthermore,  it 
appeared  that  the  general  advantages  of  reduced  confusion  and 
communication  error  that  were  achieved  with  Data  Link  might  have 
been  most  apparent  when  the  second  controller  was  added  to  the 
sector  to  assume  routine  communications. 

These  post-test  data  as  well  as  adjunct  debriefings  appear  to 
provide  some  initial  direction  in  the  current  effort  to  discover 
strategies  and  procedures  which  will  optimize  the  benefit  of 
implementing  Data  Link  in  the  terminal  ATC  environment.  The 
subjects'  rating  responses  were  based  on  a  combination  of  their 


39 


AHP  Capacity  Scaie 


0.5 


0.4 


0.3 


0.2 


0.1 


0 


Voice 


Voice  and  Data  Link 


Communication  Mode 


Arrival/Final  Sector 

Single  Controller  ;  I  Two  Controllers 


FIGURE  3.  PROJECTED  EFFECTS  OF  TEAM  SIZE  ON  CAPACITY 


40 


AHP  Safety  Scale 


0.5 

0.4 

0.3 

0.2 


Voice  Voice  and  Data  Link 

Communication  Mode 

Arrival/Final  Sector 

HI  Single  Controller  Two  Controllers 

FIGURE  4.  PROJECTED  EFFECTS  OF  TEAM  SIZE  ON  SAFETY 


41 


operational  expertise  in  performing  terminal  ATC  tasks  and 
reflection  on  their  experiences  in  the  Data  Link  Test  Bed  during 
which  they  experimented  with  the  use  of  voice  and  Data  Link  under 
unconventional  conditions.  The  test  runs  were  not  designed  to  test 
the  operational  feasibility  of  combining  arrival  and  final  approach 
sectors  or  the  use  of  multiple  controllers  at  such  sectors.  Rather, 
the  situation  was  devised  in  order  to  permit  the  controllers  to 
explore  options  for  using  Data  Link  which  might  not  have  been 
apparent  under  more  typical  ATC  conditions. 

The  data  collected  from  the  questionnaire  indicate  that  one  way  in 
which  the  benefits  of  Data  Link  can  be  enhanced  is  through  the  use 
of  controller  teams.  These  projected  benefits  of  increased  safety 
and  capacity  appear  to  be  primarily  attributable  to  the  fact  that 
Data  Link  provides  a  second  communication  channel  to  the 
controller.  While  the  second  channel  may  be  beneficial  to  a  single 
controller,  it  appears  that  these  benefits  are  multiplied  when  a 
second  controller  is  added.  Such  benefits  seem  to  be  greatest 
under  special  conditions  when  the  assistant  can  use  Data  Link  to: 

(1)  send  routine  messages  during  periods  of  high  traffic  load,  and 

(2)  help  to  avoid  traffic  delays  by  using  Data  Link  to  maintain 
traffic  flow  while  the  primary  controller  deals  with  an  error 
condition  or  emergency.  The  data  does  not  indicate  that  two 
controllers  are  needed  to  benefit  from  Data  Link.  The  data  does 
show  that  Data  Link  presents  the  possibility  of  devising  new  ATC 
conventions  and  strategies  which  make  optimal  use  of  the  second 
communication  channel  offered  by  this  system.  The  results  support 
the  concept  that  test  scenarios  and  associated  experiments  should 
be  designed  which  can  be  used  to  isolate  the  conditions  under  which 
these  expected  benefits  can  be  observed  and  measured  using  both 
controller  judgments  and  performance  measures. 

3.2.2  Evaluation  of  Performance  Measures. 

As  discussed  in  section  2.1  of  this  report,  the  full  scale  test 
runs  conducted  in  Mini  Study  3  were  designed  primarily  to  provide 
the  controllers  with  a  complex,  high  density  air  traffic  situation 
in  which  alternative  strategies  for  employing  Data  Link  could  be 
explored.  Candidate  performance  measures  were  collected  during  the 
study  in  order  to  evaluate  their  potential  for  valid  application 
in  future  operational  evaluation  research.  Unlike  the  exploratory 
and  developmental  focus  of  the  study  reported  here,  operational 
evaluation  studies  will  be  designed  to  assess  and  document  the 
impact  of  the  initial  terminal  Data  Link  services  on  the  overall 
performance  of  the  ATC  system.  Performance  measures  such  as  those 
discussed  in  the  following  subsections  of  this  report  will  be 
needed  to  objectively  evaluate  Data  Link's  effects  on  system 
safety,  capacity,  and  efficiency,  as  well  as  its  efficacy  in 
reducing  congestion  of  the  voice  radio  channel. 

It  must  be  emphasized  that  the  goals  and  subsequent  design  of  the 
current  study  narrowly  restrict  interpretation  of  the  performance 
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data  reported  here  to  issues  associated  with  the  value  and 
appropriateness  of  the  candidate  measures  themselves.  For  the 
reasons  discussed  below,  no  conclusions  drawn  from  these  data 
regarding  the  impact  of  Data  Link  on  ATC  performance  are  warranted 
or  valid: 

a.  Controller  practice  and  familiarity  with  the  test  airspace 
and  with  Data  Link  inputs  and  displays  were  extremely  limited,  and 
did  not  provide  subjects  with  the  level  of  knowledge  and  facility 
that  will  be  required  of  subjects  in  an  operational  evaluation 
study.  In  such  studies,  sufficient  training  will  be  required  to 
approximate  skill  levels  that  will  be  the  norm  for  controllers 
using  a  fielded  system. 

b.  The  performance  measures  tested  in  this  study  were 
influenced  by  the  intentional  omission  of  standardized  procedures 
and  rules  for  using  Data  Link.  In  order  to  examine  strategy 
issues,  subjects  were  explicitly  instructed  to  freely  experiment 
with  alternate  uses  of  the  system  in  a  manner  which  would  not  be 
appropriate  for  a  simulation  intended  to  provide  data  aimed  at 
accurately  predicting  the  operational  impact  of  Data  Link. 

c.  As  evidenced  by  the  findings  of  the  subject  interviews 
conducted  during  full  scale  testing,  errors  and  performance 
variations  that  were  not  attributable  to  the  communication  systems 
were  introduced  by  simulation  pilots  in  this  study.  Drawing  valid 
conclusions  about  Data  Link  from  performance  metrics  during 
operational  evaluation  will  require  the  use  of  more  highly  trained 
simulation  pilots,  improved  simulation  pilot  procedures  and 
displays,  and  the  participation  of  a  subgroup  of  actual  aircraft 
pilots  in  the  test  scenarios. 

In  the  data  reported  in  the  following  subsections,  a  repeated 
measures  procedure  was  used  for  analysis  of  statistical 
significance.  The  Huynh-Feldt  correction  to  the  degrees  of  freedom 
for  the  within-subjects  Multivariate  Analysis  of  Variance  (MANOVA) 
was  applied,  when  appropriate,  to  correct  for  correlations  between 
repeated  measures. 

3. 2, 2.1  ATC  System  Safety  Measures. 

The  primary  technique  proposed  for  assessing  safety  in  future 
operational  evaluations  involves  the  use  of  algorithms  which  will 
automatically  detect  and  record  the  occurrence  of  conflicts  and 
their  severity.  Prior  test  applications  of  these  techniques  have 
indicated  that  their  sensitivity  to  aircraft  proximity  tends  to 
produce  a  large  number  of  false  alarms.  Thus,  interpretation  of 
the  data  required  extreme  caution  and  detailed  qualitative  analysis 
of  the  aircraft  track  records  to  determine  the  validity  of  a 
detected  conflict,  its  cause,  and  operational  significance.  The 
results  of  the  current  s+’udy  confirmed  this  conclusion. 
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A  majority  of  the  automatically  detected  conflicts  were  eliminated 
from  the  raw  NSSF  data  file  using  a  set  of  rules  designed  to  filter 
out  false  alarms.  The  shortened  list  contained  several  conflicts 
with  low  API’s  and  high  CPA's.  All  of  these  potential  conflicts 
were  between  aircraft  within  a  sector  rather  than  between  aircraft 
in  two  different  sectors,  and  a  majority  occurred  in  the  combined 
arrival/ final  sectors. 

Qualitative  analyses  were  conducted  on  the  10  conflicts  with  API's 
greater  than  40.  Three  of  these  were  discounted  as  attributable 
to  scenarios  problems  or  recording  system  errors,  and  were  not 
related  in  any  way  to  controller  activities.  Of  the  remaining 
seven  conflict  detections,  four  occurred  in  the  single  controller 
conditions  (two  in  voice  and  two  in  Data  Link) .  No  conflicts  were 
detected  in  the  team  voice  conditions  and  three  in  the  team  Data 
Link  conditions.  However,  analyses  of  the  aircraft  track  and 
communications  records  did  not  indicate  that  the  communications 
conditions  under  which  the  potential  errors  were  detected  were  a 
causal  factor  in  either  the  single  controller  or  team  conditions. 

Further  evidence  supporting  the  need  for  qualitative  analysis  as 
well  as  automatic  recording  of  conflicts  in  future  operational 
evaluations  was  obtained  from  notes  that  the  controller  subjects 
were  asked  to  maintain  of  separation  violations  that  they  detected 
during  the  test  runs.  The  controllers  recorded  a  total  of  21 
conflicts  of  which  13  did  not  appear  on  the  filtered  NSSF  listing. 
Three  of  the  seven  NSSF  conflicts  with  API  scores  over  40  were 
contained  in  the  controller  lists. 

3. 2. 2. 2  ATC  System  Capacity  Measures. 

The  number  of  aircraft  a  controller  is  able  to  handle  over  a  period 
of  time  while  employing  a  given  ATC  technology  was  selected  as  one 
of  the  primary  candidate  measures  of  system  capacity  for  future 
operational  evaluation.  Other  measures  tested  in  this  study  for 
assessing  capacity  included  aircraft  spacing  on  final  approach, 
time  between  landings,  and  number  of  aircraft  crossing  the  runway 
threshold  per  unit  time. 

The  data  for  number  of  aircraft  handled  were  separated  into 
individual  and  team  conditions  for  the  arrival/final  sectors.  The 
number  of  aircraft  handled  per  run  was  divided  by  the  total  number 
of  minutes  in  the  session  to  adjust  for  different  scenario  lengths. 
The  departure  sectors  were  not  tested  because  traffic  load  was  held 
constant  during  all  scenarios. 

A  MANOVA  was  used  to  test  the  one  between-subjects  variable  and 
one  wiLhin-subjects  variable  design  for  the  single  controller 
arrival/final  runs.  The  analysis  showed  that  the  main  effect  of 
communication  type  was  not  significant,  F(l,  4)  =  .28,  p  =  .6256, 
but  indicated  that  the  effect  of  side  of  airspace  was  significant, 
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F ( 1 ,  4)  =  10.07,  p  =  .0337.  The  interaction  of  the  two  factors 
was  not  significant,  F(l,  4)  =  1.32,  p  =  .3141. 

The  results  for  the  team  arrival/final  runs  indicated  that  the  main 
effect  of  communication  type  on  number  of  aircraft  handled  per 
minute  was  not  significant,  F(l,  4)  =  .68,  p  =  .4553,  and  that  the 
effect  of  side  of  airspace  was  not  significant,  F(l,  4)  =  .002, 
p  =  .9694.  The  interaction  of  the  two  factors  was  also  not 
significant,  F(l,  4)  =  1.32,  p  =  .3141. 

Aircraft  spacing  on  final  also  was  measured  to  assess  its  value  as 
a  measure  of  capacity.  As  each  arriving  aircraft  crossed  the 
runway  threshold,  the  straight-line  distance  to  the  next  arriving 
aircraft  was  calculated.  A  potential  limitation  of  this  method  is 
that  aircraft  injected  into  the  approach  stream  between  two  others 
shortly  after  a  measurement  had  been  taken  would  not  immediately 
turn  up  in  the  file  of  spacing  data.  However,  it  was  expected  that 
the  improvement  in  spacing  would  be  counted  as  the  injected 
aircraft  landed.  To  test  for  the  impact  of  this  factor  on  the 
spacing  measure,  the  r amber  of  aircraft  injected  into  the  normal 
arrival  flow  during  the  full  scale  simulation  runs  were  counted. 
Injected  aircraft  events  only  occurred  10  times  out  of  a  possible 
531  landings.  Thus,  it  appears  that  the  spacing  measure  will  be 
minimally  affected  by  this  possibility  in  future  evaluations. 

Another  related  technique  for  assessing  capacity  was  to  consider 
elapsed  time  between  landings.  Given  that  traffic  density  was 
increasing  as  a  function  of  simulator  time  in  each  scenario,  it 
’  as  assumed  that,  if  the  spacing  and  timing  measures  were  valid 
indicators  of  capacity,  some  decrease  would  automatically  occur  as 
each  scenario  progressed. 

Average  spacing  and  timing  on  final  for  each  controller  were 
averaged  over  1,000  second  "windows"  during  each  simulation.  The 
data  were  submitted  to  statistical  testing  using  MANOVA.  The 
results  indicated  that,  for  individual  Data  Link  and  voice  data, 
there  was  no  significant  effect  of  communication  type  or  side  of 
airspace  on  spacing,  F(l,  4)  =  .76,  p  =  .4331,  F(l,  4)  =  11.58, 
p  =  .0735.  The  interaction  of  scenario  time  and  side  was  also  not 
significant,  F(l,  4)  =  .15,  p  =  .7183,  and  there  was  no  effect  of 
scenario  time  on  spacing,  F(2,  4)  =  3.6,  p  =  .0768. 

There  was  also  no  significant  effect  of  communication  type  or  side 
of  airspace  on  time  between  landings,  F(l,  4)  =1.73,  p=  .2587, 
F ( 1 ,  4)  =  4.67,  p  =  .0967.  The  interaction  of  scenario  time  and 
side  was  also  not  significant,  F(l,  4)  =  .8,  p  =  .4214,  and  there 
was  no  effect  of  scenario  time  on  time  between  landings,  F(2,  4) 
=  . 92 ,  p  =  . 4353 . 

For  the  team  Data  Link  and  voice  data,  there  was  no  significant 
effect  of  communication  type  or  side  of  airspace  on  spacing,  F(l, 
4)  =  .32,  p  =  .5998,  F(l,  4)  =  6.69,  p  =  .0609.  The  interaction 
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of  scenario  time  and  side  was  also  not  significant,  F(l,  4)  = 
.3.86,  p  =  .1208,  but  there  was  a  significant  effect  of  scenario 
time  on  spacing  (as  shown  in  figure  5),  F(2,  4)  =  4.8,  p  =  .0422. 

There  was  no  significant  effect  of  communication  type  or  side  of 
airspace  on  time  between  landings,  F(l,  4)  =3.05,  p=  .1555,  F(l, 
4)  =  1.85,  p  =  .2452.  The  interaction  of  scenario  time  and  side 
was  also  not  significant,  F(l,  4)  =  .1.0,  p=  .3734,  but  there  was 
a  significant  effect  of  scenario  time  on  time  between  landings  (as 
shown  in  figure  6),  F(2,  4)  =4.57,  p  =  .0474. 

The  above  statistical  tests  demonstrate  that  the  measures  of 
spacing  on  final  and  time  between  landings  should  be  sensitive  to 
effects  of  communications  technology  evaluated  in  future 
operational  evaluation  studies.  The  measures  successfully 
reflected  the  expected  impact  of  increasing  traffic  density  over 
the  course  of  the  simulation  runs  under  team  conditions.  The  fact 
that  the  effects  were  confined  to  the  team  controller  test 
conditions  can  be  seen  as  further  evidence  that  the  measures  will 
validly  assess  capacity,  since  they  appear  to  have  shown  the 
contribution  of  the  additional  controller  to  the  ability  to 
effectively  respond  to  increasing  traffic  levels. 

The  rate  of  landings  also  was  tested  as  a  measure  of  capacity.  To 
obtain  this  measure,  the  number  of  aircraft  landed  in  the 
arrival/final  sectors  during  each  run  was  calculated.  Statistical 
analysis  detected  no  significant  effect  of  communication  type  for 
the  individual  controller  runs,  F(l,  4)  =4.02,  p=  .  Ij.58  or  for 
side  of  the  airspace,  F(l,  4)  =  5.14,  p  =  .0861.  There  also  was 
no  significant  effect  of  the  interaction  of  communication  condition 
and  side  of  airspace,  F(l,  4)  =  2.02,  p  =  .2279. 

The  results  for  the  team  runs  for  rate  of  landings  also  showed  no 
significant  effect  of  communication  type,  F(l,  4)  =  2.81,  p  = 
.1591,  but  there  was  a  significant  difference  between  side  of 
airspace,  F(l,  4)  =  17.6,  p  =  .0137.  There  was  no  significant 
interaction  of  communication  type  and  side  of  airspace,  F(l,  4)  = 
5.07,  p  =  .0876. 

3. 2. 2. 3  ATC  System  Efficiency  Measures. 

As  candidate  measures  of  efficiency,  the  NSSF  system  measured  the 
amount  of  time  an  aircraft  spent  in  each  sector  and  how  far  it  flew 
(between  controller  acceptance  and  handoff) .  Times  and  distances 
can  be  expected  to  be  partially  dependent  upon  controller  style, 
especially  in  departure  sectors  where  it  is  possible  to  handoff  an 
aircraft  early,  if  all  necessary  instructions  have  been  given. 
However,  if  it  is  assumed  that  a  given  controller  would  use  the 
same  approach  under  both  Data  Link  and  voice  conditions,  any 
improvements  in  flight  time  or  distance  flown  that  are  measured  in 
future  operational  evaluations  should  be  attributable  to  an 
advantage  offered  by  one  of  the  communication  media. 
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A  specific  advantage  of  measuring  time  and  distance  while  under 
control  is  the  possibility  of  measuring  how  much  controller 
intervention  is  required  by  each  aircraft  flight.  In  some  sectors, 
improvements  in  communication  may  decrease  the  amount  of  "occupancy 
time"  for  each  aircraft,  thus  freeing  the  controller  to  handle 
other  aircraft.  The  following  results  suggest  that  this  may  be 
possible,  but  that  the  addition  of  a  second  communicating 
controller  may  confound  the  hypothesized  relationship  between 
flight  time/distance  and  efficiency. 

3. 2. 2. 3.1  Flight  Time. 

Flight  time  data  were  divided  into  sets  for  individual  versus  team 
in  arrival/final  sectors.  Departure  sectors  were  considered 
separately  and  an  independent  analysis  was  conducted  on  each  set. 
Only  the  first  25  aircraft  were  included  in  each  analysis  in  order 
to  eliminate  those  which  started  but  did  not  complete  their  flight 
plans  before  the  end  of  the  simulation  run.  Flight  time  for  each 
aircraft  was  measured  and  average  flight  time  for  each  controller 
over  each  run  was  calculated. 

A  MANOVA  for  the  individual  arrival/final  data  showed  that  the  main 
effect  of  communication  type  on  flight  time  was  not  significant, 
F ( 1 ,  4)  =  5.94,  p  =  .0715,  and  that  the  effect  of  side  of  airspace 
was  also  not  significant,  F(l,  4)  =  1.0,  p  =  .3728.  The 
interaction  of  the  two  factors  was  not  significant,  F(l,  4)  = 
.009,  p  =  .9308. 

The  results  for  the  team  arrival/final  runs  indicated  that  the  main 
effect  of  communication  type  was  significant,  F(l,  4)  =  15.96, 
p  =  .0162,  and  that  the  effect  of  side  of  airspace  was  not 
significant,  F(l,  4)  =  .19,  p  =  .6845.  The  interaction  of  the  two 
factors  was  also  not  significant,  F(l,  4)  =  1.9,  p  =  .2392.  The 
results  are  plotted  in  figure  7. 

The  results  for  the  departure  sectors  showed  no  significant  main 
effect  of  communication  type,  F{1,  6)  =  .08,  p  =  .7876,  and  a 
non-significant  effect  of  side  of  airspace,  F(l,  6)  =  .22,  p  = 
.6541.  The  interaction  of  the  two  factors  was  also  not 
significant,  F(l,  6)  =  .31,  p  =  .5957. 


The  above  statistical  tests  indicated  that  there  were  no 
significant  differences  in  flight  times  under  individual  controller 
conditions,  but  that  aircraft  spent  a  longer  time  under  control  in 
the  arrival/final  sectors  when  the  controllers  worked  in  teams. 
This  finding  may  be  attributable  to  the  fact  that,  unlike  the 
voice-only  team  conditions,  there  were  two  controllers  actively 
handling  each  aircraft  in  Data  Link  team  conditions.  Thus,  the 
additional  path  changes,  earlier  acceptances,  and  later  handoffs 
which  may  have  increased  flight  time  could  reflect  the  ability  of 
two  controllers  to  relay  more  useful  messages  via  Data  Link  to 
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aircraft  under  high  traffic  conditions,  rather  than  a  difference 
in  efficiency. 

3. 2. 2. 3. 2  Distance  Flown. 

Average  distance  flown  in  each  sector  while  under  control  was  also 
measured.  Distance  data  for  arrival/final  sectors  were  separated 
into  sets  for  individual  versus  team  conditions.  Departure  sectors 
were  considered  separately  and  an  independent  analysis  was 
conducted  on  each  set.  Only  the  first  25  aircraft  were  included 
in  each  analysis  in  order  to  eliminate  those  which  started  but  did 
not  complete  their  flight  plans  before  the  end  of  the  simulation 
run. 

A  MANOVA  was  used  to  test  the  individual  arrival/final  runs  and  it 
was  found  that  both  the  main  effects  of  communication  type, 
F ( 1 ,  4)  =  1.27,  p  =  .3234,  and  of  side  of  airspace  were  not 
significant,  F(l,  4)  =  6.81,  p  =  .0595.  The  interaction  of  the  two 
factors  was  also  not  significant,  F(l,  4)  =  .64,  p  =  .4694. 

The  results  for  the  team  arrival/final  runs  indicated  that  the  main 
effect  of  communication  type  was  significant,  F(l,  4)  -  8.41,  p  = 
.0441,  and  that  the  effect  of  side  of  airspace  was  marginally 
significant,  F(l,  4)  =  7.6,  p  =  .0511.  The  interaction  of  the  two 
factors  was  not  significant,  F(l,  4)  =  3.38,  p  =  .1397.  The  cell 
means  are  plotted  in  figure  8. 

The  results  for  the  departure  sectors  were  not  significant  for 
communication  type,  F(l,  6)  =  .24,  p  =  .6437,  or  for  side  of 
airspace,  F(l,  6)  =  .01,  p  =  .9082.  The  interaction  of  the  two 
factors  was  also  not  significant,  F(l,  6)  =  .46,  p  =  .5221. 

In  parallel  with  the  flight  time  data,  the  distance  flown  results 
indicate  that  in  the  team  Data  Link  arrival/final  conditions, 
aircraft  flew  farther  while  under  control.  As  suggested  above, 
this  pattern  of  results  indicates  that  caution  must  be  observed 
when  using  these  measures  for  operational  evaluation  because  rather 
than  a  drop  in  efficiency,  the  increase  in  distance  and  time  may 
have  been  attributable  to  an  increased  level  of  communications 
effectiveness  (e.g.,  earlier  handoff  acceptance  would  create  longer 
distances  and  times) . 

3. 2. 2. 4  Voice  and  Data  Link  Usage  Measures. 

3. 2. 2. 4.1  Voice. 

In  previous  studies  in  which  communications  measures  were 
evaluated,  use  of  the  voice  radio  system  to  communicate  ATC 
instructions  to  aircraft  decreased  with  the  availability  of  Data 
Link.  Radio  usage  was  measured  by  totaling  the  amount  of  time 
controllers  depressed  the  push-to-talk  button  in  each  position, 
for  each  scenario.  Frequency  of  use  was  calculated  by  counting 
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FIGURE  8.  TEAM  ARRIVAL/FINAL  AVERAGE  DISTANCE  FLOWN  IN  SECTOR 
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the  number  of  times  the  microphone  button  was  pressed  and  dividing 
by  total  scenario  run  time,  to  adjust  for  scenarios  of  different 
lengths.  Because  the  measures  of  the  duration  of  voice 
communication  and  frequency  of  use  data  were  nearly  identical  in 
those  studies,  only  the  former  was  examined  in  the  present  study. 

A  test  of  the  differences  in  the  total  duration  of  voice  messages 
for  individual  arrival/final  sectors,  as  shown  in  figure  9, 
resulted  in  a  significant  main  effect  of  communication  condition, 
F ( 1 ,  4)  =  12.45,  p  =  .0243,  and  a  marginally  significant  difference 
between  sides  of  the  airspace,  F(l,  4)  =  6.88,  p  =  .0586.  Their 
interaction  was  not  significant,  F(l,  4)  =  2.57,  p  =  .1845. 

During  the  team  arrival/final  runs,  there  was  a  significant  main 
effect  of  communication  type  on  total  voice  communication  time, 
F ( 1 ,  4)  =  8.67,  p  =  .0422,  but  the  effect  of  side  of  airspace  was 
not  significant,  F(l,  4)  =  4.76,  p  =  .0945.  The  interaction  of 
the  two  factors  was  also  not  significant,  F(l,  4)  =  .92,  p  =  .3927. 
The  cell  means  are  plotted  in  figure  10. 

In  the  departure  sectors  there  was  a  significant  effect  of 
communication  type  on  total  message  duration,  F(l,  6)  =  70.48,  p 
=  .0002,  but  not  for  side  of  airspace,  F(l,  6)  =  2.9,  p  =  .1394. 
The  interaction  of  the  two  factors  was  not  significant,  F(l,  6)  = 
.21,  p  =  .6660.  The  cell  means  are  plotted  in  figure  11. 

The  results  presented  above  confirm  prior  tests  of  measures  of 
voice  frequency  usage.  As  expected,  under  all  test  conditions  the 
availability  of  Data  Link  communications  with  80  percent  of  the 
aircraft  produced  significant  drops  in  voice  frequency  usage.  The 
consistency  of  this  metric  across  several  exploratory  studies  in 
both  terminal  and  en  route  Data  Link  development  indicates  that  it 
is  likely  to  provide  a  valid  quantitative  indicator  of  the  degree 
of  Data  Link's  effect  on  voice  frequency  congestion  in  future 
operational  evaluation  studies. 

3. 2. 2 .4. 2  Data  Link. 

To  provide  a  candidate  measure  of  the  way  in  which  Data  Link  is 
used  by  the  controller,  records  of  Data  Link  communications  were 
reduced  in  order  to  count  the  frequency  of  MT,  TI,  and  TC  messages 
sent  by  controllers  under  various  conditions. 

Figure  12  shows  the  rate  of  sending  Data  Link  MT  and  TI  messages 
for  the  arrival/final  sectors  (no  TC  messages  were  sent  in  these 
positions) .  (Message  frequency  was  divided  by  the  total  run  time 
of  each  scenario  to  adjust  for  differences  in  scenario  length) . 
Figure  13  shows  MT,  TI ,  and  TC  messages  for  the  departure  sectors. 

The  data  indicate  that  the  rate  of  Data  Link  transmissions  for  MT 
messages  was  higher  in  the  team  condition  while  the  rate  of  TI 
messages  remained  about  the  same  for  individual  and  team  controller 
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FIGURE  9.  TOTAL  DURATION  OF  VOICE  MESSAGES  FOR  INDIVIDUAL  ARRIVAL/FINAL  SECTORS 
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FIGURE  10.  TOTAL  DURATION  OF  VOICE  MESSAGES  FOR  TEAM  ARRIVAL/FINAL  SECTORS 
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FIGURE  11.  TOTAL  DURATION  OF  VOICE  MESSAGES  FOR  DEPARTURE  SECTORS 
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FIGURE  12.  RATE  OF  SENDING  DATA  LINK  MT  AND  TI  MESSAGES  FOR  ARRIVAL/FINAL 
SECTORS 


FIGURE  13.  RATE  OF  SENDING  DATA  LINK  MT,  TC,  AND  TI  MESSAGES  FOR 
DEPARTURE  SECTORS 
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configurations.  Rates  of  message  transmission  in  the  departure 
sectors  were  generally  lower  and  were  in  different  relative 
proportions.  Departure  sector  controllers  sent  more  TI  as  compared 
to  MT  messages  while  the  opposite  was  true  in  arrival/ f inal 
sectors. 

In  Mini  Study  2,  videotape  records  were  made  of  controller  Data 
Link  entries  and  it  was  found  that  an  average  of  3.7  seconds  were 
required  to  key  in  a  TI  or  MT  selection,  scroll  the  trackball  to 
locate  the  cursor  over  the  target  aircraft,  and  press  the  ENTER 
key.  In  Mini  Study  3,  this  average  composition  time  was  used  to 
estimate  the  amount  of  time  controllers  spent  formatting  and 
transmitting  Data  Link  messages. 

Figure  14  shows  the  estimated  average  proportion  of  run  time  spent 
composing  Data  Link  messages  for  arrival/final  controllers  in  the 
individual  and  team  Data  Link  with  voice  conditions.  With  the 
extra  person  available,  it  appears  that  Data  Link  was  used  somewhat 
more  in  the  West  side  of  the  airspace.  In  the  departure  sectors, 
Data  Link  message  composition  took  up  10.8  percent  of  the 
controller's  time. 

3.2. 2.4.3  Voice  and  Data  Link. 

The  use  of  time  measurements  to  make  a  valid  comparison  of  voice 
and  Data  Link  in  future  operational  evaluations  must  be  approached 
with  caution.  While  estimating  Data  Link  message 
selection/composition  times  from  keyboard  activity  observations  is 
a  relatively  straightforward  task,  comparing  these  times  to  the 
time  spent  speaking  on  the  voice  radio  presents  complications. 
While  both  measures  provide  a  total  observable  activity  time,  they 
do  not  necessarily  reflect  the  time  spent  engaging  in  the  mental 
activity  required  to  generate  the  desired  message.  Such  activity 
could  precede  the  observed  behaviors,  or  occur  simultaneously  with 
them.  Thus,  voice  and  Data  Link  comparisons  may  be  misleading. 
In  addition,  while  time  measures  are  likely  to  be  correlated  with 
message  length  and  complexity  in  the  case  of  voice,  selection  of 
a  lengthy  message  from  a  Data  Link  menu  should  take  no  more  time 
than  selection  of  a  brief  message.  Therefore,  comparisons  will  be 
strongly  affected  by  the  types  of  messages  sent  by  controllers  in 
a  specific  scenario. 

Despite  these  limitations,  the  results  from  the  preceding  two 
sections  were  combined  to  examine  the  differences  between  speaking 
times  and  Data  Link  data  entry  times.  The  data  for  individual  and 
team  controller  configurations  were  considered  separately. 
Combining  the  data  in  this  way  assumes  that  the  task  of  voicing  an 
instruction  to  an  aircraft  is  equivalent  to  keying  an  instruction 
into  the  Data  Link  system,  and  that  the  same  types  of  messages  were 
sent  in  both  communications  modes. 
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FIGURE  14.  ESTIMATED  TOTAL  TIME  COMPOSING  AND  SENDING  DATA  LINK  MESSAGES 
FOR  ARRIVAL/FINAL  SECTORS 


Figures  15  and  16  combine  NSSF  data  for  total  length  of  voice 
transmissions  in  the  arrival/final  sectors  (expressed  as  a 
proportion  of  total  run  time)  with  the  time  required  to  compose  and 
send  Data  Link  messages  estimated  during  the  previous  Data  Link 
Mini  Study.  For  the  individual  controller  runs,  there  appears  to 
have  been  little  difference  in  the  amount  of  time  spent  using  a 
combination  of  Data  Link  and  voice  as  compared  to  voice-only. 
However,  in  the  team  configurations,  somewhat  more  total  time  may 
have  been  involved  when  Data  Link  and  voice  were  both  available, 
as  might  be  expected  with  the  provision  of  the  second  controller. 

The  results  for  the  departure  sectors  tell  a  similar  story  when 
total  time  spent  communicating  was  considered,  as  shown  in  figure 
17.  In  the  arrival/final  sectors,  Data  Link  messages  made  up  about 
one-half  of  the  time  spent  communicating  during  Data  Link  with 
voice  runs.  Departure  controllers  appeared  to  use  Data  Link  more 
often  when  it  was  available,  accounting  for  about  two-thirds  of 
total  message  time. 

3.2.3  Discussion  of  Performance  Measures. 

3. 2. 3.1  Safety  Measures. 

The  monitoring  of  predefined  aircraft  conflict  parameters  continues 
to  be  the  only  approach  available  for  automated  measurement  of 
system  safety  in  future  operational  evaluations.  As  shown  in  the 
present  study,  current  methods  for  computerized  conflict  recording 
resulted  in  a  number  of  false  detections,  and  were  not  necessarily 
correlated  with  controller  records  of  conflicts.  Rule-based 
filters  for  excluding  false  alarms  were  developed  for  this  study 
which  proved  successful  for  eliminating  some  incorrect  detections. 
However,  in  order  to  decrease  reliance  on  qualitative  methods  for 
screening  automatically  detected  conflicts,  additional  filtering 
rules  based  on  accepted  ATC  conventions  may  be  needed.  An 
alternative  to  such  sophisticated  screening  rules  addition  that  was 
tested  in  the  present  study  is  to  restrict  qualitative  analyses  to 
detected  conflicts  of  long  duration,  high  API,  or  low  CPA.  Such 
an  approach  should  prove  to  be  efficient  for  future  tests  of  the 
impact  of  Data  Link  on  safety.  Additionally,  efforts  should  be 
made  to  validate  NSSF  based  conflict  measures  by  comparing  them  to 
the  conflict  records  provided  by  the  ARTS  system. 

3. 2 .3. 2  Capacity  Measures. 

The  new  approaches  developed  and  examined  in  Mini  Study  3  for 
assessing  the  effects  of  Data  Link  on  system  capacity  in  future 
operational  evaluations  included  measures  of  spacing  and  time 
between  landings  on  final  and  the  rate  of  landings.  The 
demonstrated  sensitivity  of  these  measures  to  increasing  traffic 
demands  in  some  test  conditions  suggests  that  they  may  be  useful 
in  operational  evaluation.  However,  the  results  of  the  current 
study  also  indicate  that  the  selection  of  appropriate  measures  of 
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FIGURE  15.  TOTAL  TIME  SPENT  COMMUNICATING  USING  DATA  LINK  AND/OR  VOICE 
IN  THE  INDIVIDUAL  ARRIVAL /FINAL  SECTORS 
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FIGURE  16.  TOTAL  TIME  SPENT  COMMUNICATING  USING  DATA  LINK  AND/OR  VOICE 
IN  THE  TEAM  ARRIVAL /FINAL  SECTORS 
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17.  TOTAL  TIME  SPENT  COMMUNICATING  USING  DATA  LINK  AND/OR  VOICE 
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capacity  will  depend  upon  how  Data  Link  is  employed  by  the  test 
controllers. 

For  example,  the  current  study  yielded  no  significant  differences 
between  Data  Link  and  voice  on  the  tested  system  capacity  measures. 
The  strategy  data  indicate  that  this  result  is  probably 
attributable  to  the  way  in  which  the  controllers  distributed 
messages  between  Data  Link  and  voice.  It  appears  that  most 
controllers  in  Mini  Study  3  did  not  use  Data  Link  to  negotiate  *che 
control  of  aircraft  on  final  approach.  Voice  was  preferred 
primarily  for  its  rapid  transmission  and  response  capabilities. 
Therefore,  controllers  were  using  voice  in  both  Data  Link  and  voice 
scenarios  to  accomplish  the  tasks  which  would  have  the  greatest 
effect  on  the  spacing  measures  that  were  collected.  The  only 
benefit  that  Data  Link  could  have  in  such  situations  would  be  to 
indirectly  effect  spacing  on  final  by  perhaps  creating  a  more 
consistent  traffic  flow. 

As  suggested  by  the  strategy  data,  it  appears  that  additional, 
scenario-specific  measures  may  be  needed  in  operational  evaluation 
to  detect  Data  Link's  hypothesized  indirect  effects  on  capacity 
produced  by  the  ability  to  employ  two  available  communications 
channels.  Nevertheless,  the  measures  employed  during  Mini  Study 
3  should  continue  to  be  used  as  general  indicators  of  system 
capacity. 


3 . 2 ■ 3 . 3  Efficiency  Measures . 

The  performance  measures  of  flight  time  and  distance  flown  while 
under  control  are  measures  of  efficiency  that  have  a  high  level  of 
face  validity.  However,  as  noted  earlier,  they  must  be  interpreted 
in  conjunction  with  measures  of  effectiveness  and  of  controller 
strategies.  Another  measure  of  efficiency  which  should  be 
considered  is  time  and  distance  as  measured  between  sector 
boundaries.  Further  investigation  of  measures  of  time  and  distance 
should  be  made  to  determine  the  best  metrics  for  future  Data  Link 
studies. 

A  problem  with  conducting  statistical  analysis  of  the  data  from 
experiments  such  as  Mini  Study  3  is  that  some  information  is  lost 
when  averaging  over  observations.  (In  the  case  of  efficiency 
measures,  each  aircraft's  flight  through  a  sector  can  be  considered 
as  an  observation.)  The  statistical  computations  involved  to  use 
the  observation  data  are  very  complex,  especially  in  the  case  of 
the  design  employed  in  Mini  Study  3.  The  analysis  could  be 
simplified  for  an  operational  evaluation  with  an  experimental 
design  which  includes  fewer  factors. 

3. 2. 3. 4  Voice  and  Data  Link  Usage. 

Although  some  voice  traffic  may  occur  to  correct  or  modify  Data 
Link  transactions,  there  was  still  a  substantial  decrease  in  voice 
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usage  when  Data  Link  was  available.  Measures  of  communications 
errors  should  be  added  to  system  usage  measures  in  order  to  provide 
a  complete  measure  of  the  comparative  effectiveness  of  the  voice 
and  Data  Link  systems  during  operational  evaluations. 

Improved  measures  of  message  content  identified  by  tne  sending 
controller  will  also  be  desirable  for  operational  evaluation 
research.  Accurate  comparisons  of  voice  and  Data  Link  will  require 
efficient  methods  for  analyzing  the  type  and  complexity  of  each 
message  sent.  Further  efforts  also  should  be  made  to  develop 
computerized  recording  methods  for  capturing  Data  Link  message 
composition  durations  and  errors. 

4.  CONCLUSIONS. 

The  results  of  the  study  presented  in  this  report  warrant  a  number 
of  specific  and  general  conclusions  regarding  the  initial  terminal 
air  traffic  control  (ATC)  services,  required  changes  to  the  service 
designs,  controller  strategies  for  maximizing  the  effectiveness  of 
Data  Link,  the  development  of  performance  measures,  and  future 
research  and  development  efforts. 

Data  Link  Service  Designs: 

a.  The  design  review  phase  of  this  study  confirmed  the 
acceptability  and  utility  of  the  modifications  to  the  initial 
terminal  Data  Link  services  that  were  based  on  the  results  of  the 
November  1991  study.  In  addition,  the  design  review  generated  a 
limited  number  of  additional  service  enhancements  for  incorporation 
in  Data  Link  Test  Bed  software  and  the  functional  design 
specification.  Among  the  most  important  of  the  modifications 
recommended  by  the  Air  Traffic  Data  Link  Validation  Team  (ATDLVT) 
controllers  were  improvements  to  the  menu-based  service  designs 
intended  to  ensure  maximum  adaptability  to  the  full  range  of  field 
requirements.  These  included:  (1)  an  increase  in  the  flexibility 
with  which  terminal  information  (TI)  and  menu  text  (MT)  items  can 
be  combined  for  uplink,  (2)  inclusion  of  automation  and  editing 
utilities  to  permit  rapid  adaptation  and  modification  of  items  in 
the  TI  list,  and  (3)  removal  of  restrictions  on  the  number  of  items 
in  the  MT  list  that  can  be  used  for  speed,  heading,  altitude,  and 
multiple  clearances. 

b.  The  results  of  the  design  review  also  confirmed  that  human 
factors  design  features  added  to  the  MT  and  TI  service  have 
enhanced  the  usability  of  these  menu-based  services.  Controller 
ratings  of  the  impact  of  modifications  aimed  at  reducing  display 
clutter,  improving  the  ease  of  item  selection,  and  reducing  item 
selection  errors  indicated  that  each  of  these  features  has  the 
potential  to  improve  controller  performance. 

c.  Design  debriefing  results  obtained  after  the  full  scale 
simulation  exercise  suggested  that  two  general  human  factors  issues 
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warrant  further  consideration  in  the  development  of  terminal  Data 
Link  ATC  services.  Controller  comments  indicated  that  significant 
input  error  potential  may  exist  when  composing  speed,  heading,  and 
altitude  clearances  using  the  menu  bypass  function,  and  that 
messages  sent  by  Data  Link  may  be  more  easily  forgotten  than  those 
transmitted  by  voice.  The  subjects  agreed  that  if  either  of  these 
hypotheses  is  verified  in  future  research,  the  design  of  the  user 
interface  and/or  application  procedures  should  be  modified  to 
compensate  for  any  verified  decrement  in  performance. 

Further  research  also  is  needed  on  the  effect  of  Data  Link  on 
controller  situation  awareness.  Study  participants  were  concerned 
that  extensive  use  of  Data  Link  might  interfere  with  keeping  their 
"picture"  of  the  traffic  situation  since  scanning  of  the  screen  was 
disrupted  by  looking  at  Data  Link  menus  and  the  keyboard.  It  is 
recognized  that  this  concern  may  be  at  least  partly  attributable 
to  insufficient  training  with  Data  Link  operations. 

Controller  Strategies: 

d.  The  results  indicated  that  Data  Link  can  be  an  effective 
tool  when  working  in  team  conditions.  Six  of  the  eight  controllers 
said  they  preferred  Data  Link  when  working  with  another  controller 
on  the  combined  arrival/final  sector.  The  second  controller  was 
able  to  use  the  extra  Data  Link  communication  channel  to  assist  the 
primary  controller.  The  subjects  noted  that  team  Data  Link  could 
reduce  delays  in  a  busy  traffic  situation  by  using  the  second 
controller  to  send  routine  messages  and/or  to  control  traffic  flow. 
In  voice-only  team  conditions,  controllers  did  not  opt  to  share  the 
single  voice  channel,  and  reported  that  no  team  advantage  was 
obtainable  under  this  condition. 

e.  Experimentation  with  team  control  concepts  elucidated  some 
of  the  strategic  control  options  made  possible  by  Data  Link.  These 
ranged  from  highly  defined  duties  for  each  teammate  to  a  sharing 
of  all  control  tasks.  Such  strategies  appeared  to  provide 
controllers  with  a  wider  range  of  methods  for  dealing  with 
increased  traffic  loads  than  those  available  under  the  current 
single  communication  channel  system. 

While  team  control  does  not  appear  to  be  necessary  to  gain  Data 
Link  benefits,  its  advantages  were  more  apparent  under  team 
conditions  in  the  present  study.  If  this  concept  were  pursued  in 
future  work,  further  study  of  team  interaction  styles  would  be 
needed  to  determine  the  most  effective  management  of  roles  and 
resources  for  optimum  efficiency  and  safety.  Comments  made  by 
participants  suggested  that  more  practice  in  working  together  would 
be  needed  to  improve  team  effectiveness  and  safety. 

f.  Controller  projections  of  operational  impact  indicated  that 
team  size  would  not  effect  individual  workload,  but  that  the 
availability  of  Data  Link  could  permit  a  two-controller  team  to 


67 


achieve  increases  in  system  capacity  and  safety.  Both  of  these 
effects  were  attributed  to  the  increased  ability  to  make  use  of 
dual  communication  channels  when  two  controllers  staff  a  sector. 

g.  Controllers  continue  to  see  the  communication  delay 
inherent  in  Data  Link  technology  as  a  potential  problem  which  may 
limit  its  use  in  some  terminal  applications.  During  the  strategy 
discussions,  several  controllers  noted  that  Data  Link  was  not 
suitable  for  time  critical  instructions  in  the  arrival/final 
sectors,  such  as  turning  aircraft  onto  final  or  dealing  with  missed 
approaches  or  conflicts.  Data  Link  was  said  to  be  most  effective 
for  TI,  MT  clearances,  altitude  assignments,  heading  changes,  and 
speed  changes,  but  not  for  conflict  resolutions  or  the  handling  of 
missed  approaches.  Other  than  Data  Link  delays,  the  controllers 
noted  that  limited  Data  Link  training  time  in  the  current  study  was 
responsible  for  other  difficulties  experienced  in  use  of  the 
system. 

Performance  Measures: 

h.  A  number  of  the  performance  measures  evaluated  in  this 
study  appeared  to  show  promise  for  future  application  in 
operational  evaluation  where  proposed  Data  Link  benefits  to  the 
ATC  system  will  be  directly  tested  using  the  finalized  service 
designs. 

Automatic  conflict  detections  continue  to  be  the  primary  source  of 
objective  data  regarding  system  safety.  However,  as  shown  by  this 
study,  to  be  valid,  these  measures  must  be  supplemented  by 
qualitative  analyses  to  determine  the  cause  of  a  detected  incident 
and  its  operational  significance.  Several  measures  of  capacity  and 
efficiency  were  examined  in  this  study.  While,  in  most  cases,  the 
testing  conditions  did  not  include  manipulations  that  would 
conclusively  demonstrate  their  sensitivity  or  validity,  the  results 
indicated  that  valid  measures  must  be  closely  tied  to  the 
strategies  used  by  subjects  to  control  traffic  and  to  the  nature 
of  the  test  scenario.  Finally,  measures  of  voice  radio  usage 
produced  results  that  were  highly  consistent  with  those  obtained 
in  earlier  studies  and,  if  supplemented  by  measures  of 
communication  errors  and  message  content,  are  expected  to  be  valid 
for  use  in  future  operational  evaluation. 

Simulation  Procedures: 

i.  The  performance  of  simulator  pilots  appeared  to  create 
restrictions  on  controller  performance  and  the  kinds  of  strategies 
controllers  used  during  experimental  runs.  These  problems  appear 
to  have  been  a  function  of  the  simulator  pilot  Data  Link  interface 
and  training.  They  are  expected  to  be  rectified  in  the  new 
simulator  pilot  laboratory  being  installed  at  the  FAA  Technical 
Center,  and  should  not  be  a  limiting  factor  during  operational 
evaluations. 
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In  agreement  with  the  findings  of  Mini  Study  2,  the  present  results 
also  indicate  that  additional  time  should  be  allocated  for 
controller  training  and  familiarization  with  Data  Link  in  order  to 
draw  valid  conclusion  in  operational  evaluation  studies. 

5.  RECOMMENDATIONS. 

The  following  recommendations  for  future  actions  under  the  Federal 
Aviation  Administration  (FAA)  terminal  air  traffic  control  (ATC) 
Data  Link  program  are  derived  from  the  results  and  conclusions  of 
the  present  research: 

a.  The  results  of  the  design  review  conducted  as  part  of  this 
study  indicate  that  the  initial  terminal  Data  Link  ATC  services 
have  reached  a  high  level  of  development.  It  is,  therefore, 
recommended  that  after  the  limited  modifications  generated  by  the 
review  have  been  implemented,  these  services  be  subjected  to 
operational  evaluation  in  the  Data  Link  Test  Bed.  In  this 
evaluation,  thorough  testing  of  all  four  services  should  be 
performed  under  high  fidelity  simulation  conditions  using  a  group 
of  controllers  who  have  not  participated  in  the  design  development 
process.  As  a  minimum,  the  operational  evaluation  should  assess 
the  operational  suitability  of  the  initial  services,  and  assure 
that  their  implementation  does  not  adversely  affect  the  safety  or 
productivity  of  the  ATC  system. 

b.  The  present  research  indicated  that  the  positive  impact  of 
terminal  Data  Link  beyond  the  reduction  in  voice  radio  frequency 
congestion  may  be  greatest  in  specific  situations  where  a  second 
communication  channel  could  increase  safety  or  prevent  delays.  For 
this  reason,  it  is  recommended  that  an  adjunct  study  to  the 
operational  evaluation  be  performed  to  compare  the  effectiveness 
of  voice-only  procedures  with  a  system  supplemented  by  Data  Link 
in  the  context  of  specially  defined  terminal  scenarios.  Among 
others,  these  test  situations  should  include  cases  of  a  stuck 
microphone  and  scenarios  in  which  pilot  errors  disrupt  the  normal 
flow  of  air  traffic.  As  suggested  by  the  results  of  the  current 
study,  this  research  also  should  explore  the  possibility  of  using 
controller  team  strategies  to  resolve  these  special  problems. 

c.  As  shown  by  the  results  of  Mini  Study  2  and  confirmed  in 
the  present  study,  transaction  times  are  a  critical  determinant  of 
the  utility  of  Data  Link  for  sending  many  control  clearances  in  the 
terminal  environment.  As  a  consequence,  the  value  of  the  data 
collected  in  operational  evaluation  studies  will  be  dependent  on 
the  extent  to  which  transaction  times  accurately  reflect  those 
which  would  be  experienced  in  an  operational  implementation. 
Because  of  this,  it  is  recommended  that  research  efforts  be  pursued 
to  obtain  reliable  estimates  of  pilot  response  delays  and  Data  Link 
system  transmission  times. 
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d.  In  addition  to  operational  evaluation  research,  specific 
research  should  be  planned  to  investigate  unresolved  human  factors 
issues  which  have  emerged  from  this  and  other  terminal  Data  Link 
studies.  The  most  important  of  these  issues  are:  (1)  the 
comparative  potential  for  undetected  communication  errors  in  voice 
messages  and  Data  Link  messages  initiated  by  manual  entries,  (2) 
the  significance  and  performance  impact  of  reports  that  short  term 
memory  for  manually  entered  Data  Link  messages  may  be  poorer  than 
memory  for  messages  spoken  over  voice  radio,  and  (3)  the  impact  on 
situation  awareness  of  the  increased  ’’heads  down"  time  incurred  by 
the  addition  of  Data  Link  inputs  and  displays  to  the  controller's 
tasking.  Investigation  of  all  three  of  these  issues  should 
consider  how  the  effects  of  familiarity  and  practice  may  mitigate 
suspected  problems. 

e.  The  present  study  revealed  a  number  of  requirements  for 
improvements  in  experimental  methods  and  measurement  techniques 
that  should  be  addressed  to  enhance  their  utility  in  future 
simulation  studies.  The  following  modifications  are  recommended: 
(1)  increase  controller  training  on  Data  Link  procedures  and 
airspace  to  more  closely  approximate  operational  levels  of 
expertise,  (2)  take  steps  to  improve  simulation  pilot  performance, 
(3)  explore  improved  methods  for  evaluating  efficiency, 
communication  error,  and  situation  awareness,  (4)  improve 
experimental  power  through  more  efficient  study  design  and  analysis 
techniques,  (5)  improve  data  extraction  from  the  simulation 
computers,  and  (6)  exercise  the  experimental  performance  measures 
used  in  Data  Link  studies  in  the  context  of  other  ATC  research  to 
assist  in  validation, 
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APPENDIX  A 


AIRSPACE  DESCRIPTION 


The  North  Departure  Controller  radar 
identifies  aircraft  immediately 
after  departing  from  Raleigh-Durham 
Runway  23R.  Then  climbs  and  vectors 
the  aircraft  toward  one  of  two 
departure  gates.  As  the  aircraft 
nears  another  facilities  airspace 
__ — | the  controller  transfer  control  of 

the  flight  and  changes  the  pilots 
NORTH  DEPARTURES  \  frequency. 


The  South  Departure  Controller  radar 
identifier  aircraft  immediately 
after  departing  from  Raleigh-Durham 
Runway  23L.  Then  climbs  and  vectors 
the  aircraft  toward  one  of  two 
departure  gates.  As  the  aircraft 
nears  another  facilities  airspace 
the  controller  transfer  control  of 
the  flight  and  changes  the  pilots 
frequency. 
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EAST  ARRIVALS 
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The  East  Controller  accepts  arrival 
and  transgressing  flights  from  the 
South  and  East  of  Raleigh-Durham 
airspace.  The  flights  from  two 
arrival  areas  are  sequenced  together 
and  handed  of  to  the  East  Final 
controller  who  provides  the  flight 
instructions  for  landing. 


APPENDIX  B 

DATA  LINK  SERVICE  DESCRIPTIONS 
DESIGN  REVIEW  MATERIALS 


CONTROLLER  EVALUATION  OF 
INITIAL  DATA  LINK  TERMINAL  SERVICES 

ARTS  IIIA 


DESIGN  REVIEW  BOOKLET 
MINI  STUDY  3 


This  booklet  contains  a  series  of  questions  which  will  permit  you 
to  independently  review  and  evaluate  the  designs  of  the  terminal 
services  as  modified  by  the  results  of  the  last  study  and 
currently  implemented  in  the  ARTS  IIIA  section  of  the  Data  Link 
Test  Bed. 

Please  answer  all  questions  in  the  booklet  and  carefully  record 
any  recommendations  for  design  changes.  Explain  your  reasons  for 
suggesting  these  changes. 

Remember .  your  main  task  is  to  concentrate  on  completing  the 
booklet .  We  are  doing  the  review  in  the  Test  Bed  so  that  you  can 
examine  the  service  designs  as  you  work  on  the  booklet.  During 
this  session  it  is  not  important  to  maintain  precise  control  of 
the  air  traffic  in  the  scenario. 


REVIEWER  NAME 


B-l 


2 


INSTRUCTIONS 


This  review  is  divided  into  eight  sections.  Each  of  the  first 
seven  sections  begins  with  a  description  of  the  relevant  features 
or  services  that  will  be  addressed  by  the  following  questions. 
Please  read  these  descriptions  carefully  and  use  them  along  with 
your  observations  in  the  Test  Bed  to  answer  the  questions. 

During  this  session  you  should  switch  control  positions  between 
scenarios  so  that  you  will  be  able  to  evaluate  each  of  the 
services . 


N QIE 

In  the  following  service  descriptions: 


-  The  SLEW  command  should  be  interpreted  as  the  action  sequence 
of  acquiring  the  target  with  the  trackball  and  pressing  the 
trackball  enter  key. 

-  The  ENTER  command  should  be  interpreted  as  pressing  the 
keyboard  ENTER  key. 

-  Data  as  shown  in  a  display  or  entered  on  the  keyboard  are 
presented  in  quotation  marks.  The  quotation  marks  are  not  part 
of  the  display  or  entry. 
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GENERAL  DATA  LINK  FEATURES 
-  Data  Block  Equipage  and  Eligibility  Syibols 

The  terminal  Data  Link  design  uses  graphic  symbols  in  the  first  position  of  the  first  line  of  the  data  block 
to  indicate  whether  an  aircraft  is  equipped  with  a  functioning  Data  Link  system  and  whether  the  control 
position  displaying  the  track  is  eligible  to  communicate  with  the  aircraft.  No  symbol  in  the  data  block 
identifies  an  aircraft  that  does  not  have  Data  Link  capability.  A  "plus  sign"  (+)  indicates  that  the 
aircraft  is  equipped  to  communicate  using  Data  Link,  but  that  the  control  position  is  not  eligible  to 
communicate  with  it.  An  asterisk  (*)  identifies  an  aircraft  that  has  Data  Link  capability  and  indicates 
that  the  control  position  is  eligible  to  communicate  with  it  using  Data  Link. 


-  Data  Link  Key 

Several  functions  associated  with  the  Data  Link  system  require  the  controller  to  precede  a  command  entry 
with  a  special  keystroke.  In  the  current  design,  this  Data  Link  (D/L)  key  is  F9  on  the  AITS  IIIA  keyboard. 


-  One  Transaction  Per  Aircraft 

For  all  services,  only  one  Data  Link  transaction  per  aircraft  may  be  in  progress  at  a  time  —  Except  in  the 
case  of  a  "held"  TOC,  the  controller  may  not  uplink  a  new  message  until  the  previous  message  has  been 
wilcoed  or  a  transaction  that  has  failed  has  been  cleared  from  the  data  block  display. 


-  Transaction  Delete  Command 

An  ongoing  Data  Link  transaction,  or  one  that  has  resulted  in  a  failure,  can  be  deleted  by  pressing  the  D/L 
key  and  a  SLEW  action.  This  input  clears  the  data  block  and  status  list  displays  for  the  transaction  and 
permits  the  system  to  accept  the  next  message  to  the  aircraft.  The  input  does  not  recall  the  message  or 
prevent  it  from  reaching  the  aircraft.  No  provision  for  attempting  to  recall  a  message  that  has  been  sent 
is  included  in  the  design. 


-  Message  Resend  Cooand 

If  a  Data  Link  transaction  is  not  completed  because  of  a  technical  failure  (NAK),  the  controller  can  resend 
the  message  by  a  SLEW  action.  The  system  will  not  accept  the  resend  input  if  the  response  from  the  pilot  is 
"ONABLE"  (UNA). 


-  No  Response  Lock  Out  After  Time  out 

In  the  current  design,  the  data  block  and  status  list  display  a  timeout  message  if  the  pilot  fails  to 
respond  to  a  delivered  message  within  40  seconds.  This  display  is  an  alerting  message  for  the  controller, 
and  does  not  prevent  the  system  from  accepting  a  subsequent  "WILCO"  or  "UNABLE"  response.  The  transaction 
will  remain  open  until  one  of  these  messages  is  received  or  the  controller  enters  the  transaction  delete 
command. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  general 

operational  features  of  the  system  that  you  observed  in  the 
Test  Bed? 


YES,  THE  DESCRIPTION  IS  CORRECT 
NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  In  the  current  design,  the  transar-^- m  delete  command  clears 
the  status  displays  and  makes  it  t^ssible  to  send  another 
message  to  the  aircraft.  No  recall  attempt  (formerly  F9X)  is 
possible,  what  communication  procedures  should  be  followed 
when  a  transaction  is  deleted? 


3.  In  the  current  design,  the  message  resend  command  can  be  used 
after  a  Data  Link  transmission  failure  (NAK) .  Should  the 
resend  be  a  legal  command  in  the  operational  system  if  a  NAK 
does  not  guarantee  that  the  message  failed  to  reach  the  pilot? 
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4.  The  "time  out"  (TIM  /  T)  display  is  presented  if  the  pilot 
fails  to  wilco  or  unable  a  message  within  40  seconds.  In  the 
current  design,  this  display  is  an  alert  to  the  controller, 
and  does  not  prevent  the  system  from  receiving  a  later  pilot 
response.  Assuming  that  normal  total  transaction  times  are 
shorter  than  20  seconds,  would  the  alert  be  more  effective  if 
it  was  displayed  at  an  earlier  time?  If  yes,  when  should  it 
be  displayed? 


5.  What  should  be  done  to  improve  the  general  operational 

features  of  the  Data  Link  services  discussed  in  this  section? 
Include  any  changes  suggested  by  your  answers  to  questions 
2 .  -  4 .  above . 


THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 
CHANGES  ARE  DESIRABLE  OR  NEEDED 

THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 
CHANGES  ARE  NEEDED,  BUT  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  — 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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STATUS  LIST  AND  DATA  BLOCK 
TRANSACTION  STATUS  DISPLAYS 
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-  Function 

The  status  list  contains  intonation  on  the  status  of  up  to  15  ongoing  Data  Link  transactions  per  sector. 
Each  of  the  lines  displays  the  content  and  status  of  a  single  transaction.  The  display  on  the  third  line  of 
the  data  block  also  provides  status  and  content  data  for  an  ongoing  transaction. 


-  Status  List  and  Data  Block  Fonat 

Each  line  on  the  status  list  has  three  data  fields  displaying  the  Aircraft  ID,  the  message  content,  and  the 
current  status  of  the  transaction  (e.g.  "AAL123  TI*A  SNT"). 

The  third  line  of  the  data  block  presents  the  message  content  and  the  current  status  of  the  transaction 
(e.g.  A120D). 


-  Status  Messages 

The  abbreviations  used  for  the  status  sessages  in  the  status  list  are  "SNT"  (message  sent),  "DLV"  (message 
delivered  to  aircraft),  WIL  (pilot  wilco  received),  "MAK"  (failure  of  system  to  successfully  deliver  message 
to  aircraft),  "UNA"  (pilot  unable  to  comply  with  message),  and  TIM  (pilot  failed  to  respond  to  a  delivered 
message  within  40  seconds). 

The  third  line  of  the  data  block  does  not  display  the  message  sent  or  Wilco  status.  The  single  letters  nD", 
"N" ,  "0"  and  T  are  used  to  indicate  Delivered,  NAK,  Unable,  and  Time  out. 


-  Status  List  and  Data  Block  TI  and  HT  Message  Content 

The  content  of  a  Terminal  Information  (TI)  message  represented  in  the  status  list  and  in  the  third  line  of 
the  data  block  is  denoted  by  displaying  the  acronym  "TP,  an  asterisk,  and  the  alphabetic  letter  message 
identifier  associated  with  the  message  in  the  TI  list  (e.g.  "TI*A). 

The  content  of  a  Menu  Text  message  represented  in  the  status  list  and  the  data  block  is  represented  by  a 
shorthand  description  of  the  clearance  sent.  Altitude,  heading,  and  velocity  change  clearances  are 
abbreviated  by  "A",  "H",  and  "V",  respectively.  The  letter  is  followed  by  a  3-digit  number  indicating  the 
altitude  level  or  compass  heading,  or  a  2-digit  number  indicating  speed  (V)  in  hundreds  of  knots  (e.g. 
"A120H150V15").  If  a  left  or  right  turn  direction  was  selected  when  sending  a  heading  clearance,  the  "H"  is 
replaced  by  an  "L"  or  "R". 


-  Displays  on  Receipt  of  Wilco 

When  an  aircraft  downlinks  a  Wilco  to  a  transaction  contained  in  the  status  list,  "WIL"  is  displayed  for  8 
seconds,  after  which  all  transaction  information  is  deleted  from  the  list.  The  Wilco  response  is  indicated 
in  the  data  block  by  immediately  clearing  all  data  on  the  third  line. 
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-  "Failure"  Alerting  Displays 

If  a  transaction  results  in  a  NAK(  Unable,  or  Tine  Out,  the  message  content  display  and  the  single  letter 
indicator  ("N",  "U"  or  "T")  shown  in  the  data  block  flash  to  alert  the  controller.  The  corresponding 
messages  in  the  status  list  ("NAK",  "UNA",  "TIN")  do  not  flash. 


-  Displays  on  Resend 

If  the  controller  resends  a  message  that  has  failed,  the  failed  message  is  cleared  from  the  status  list  and 
a  new  status  entry  appears  when  the  message  is  sent. 


-  Quick-Look  Data  Block  Display 

If  a  controller  quick  looks  a  Data  Link  equipped  aircraft  that  is  under  the  control  of  another  position,  the 
third  line  of  the  data  block  will  only  be  displayed  to  the  Data  Link  eligible  controller. 


-  Inputs  to  Display/Suppress  Status  List 

The  status  list  is  displayed  by  pressing  the  D/L  key  (F9),  typing  "S"  and  ENTER.  When  the  list  is 
displayed,  the  identical  input  sequence  will  suppress  the  list. 

-  Inputs  to  Move  the  Status  List 

The  status  list  can  be  moved  to  any  position  on  the  display  by  pressing  the  F8  key,  typing  "S"  and  SLEW. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 

operation  of  the  Status  List  and  Data  Block  transaction  status 
displays  that  you  examined  in  the  Test  Bed? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 

_  NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  Do  the  abbreviated  status  messages  used  in  the  Status  List 
( SNT,  DLV ,  WIL,  NAK,  UNA,  TIM)  and  Data  Block  (D,  N,  U,  T) 
provide  sufficient  information?  Are  they  easy  to  interpret? 


3.  As  suggested  during  the  last  study,  the  Data  Block  display 
(and  the  Status  List)  now  gives  more  direct  information  about 
the  content  of  a  Menu  Text  transaction  in  progress.  Should 
the  shorthand  abbreviation  of  heading,  altitude,  and  speed 
clearances  be  included  in  the  final  design,  or  would  the  item 
identifier  number  be  sufficient?  Why? 


4.  Are  the  item  letter  identifier  displays  in  the  Data  Block  and 
Status  List  adequate  for  Terminal  Information  messages? 
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5.  Does  flashing  the  U,  N,  and  T  in  the  Data  Block  provide 

an  adequate  controller  alert  for  these  "failure"  conditions? 
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6.  Is  it  useful  to  display  "WIL"  in  the  Status  list  for  8  seconds 
after  the  wilco  is  received  from  the  aircraft?  Why  or  why 
not? 


7.  What  should  be  done  to  improve  the  design  of  the  Transaction 
Status  Displays?  Include  any  changes  suggested  by  your 
answers  to  questions  2.  -  6.  above. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  NEEDED,  UH  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  — 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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HISTORY  LIST 


-  Function 

The  history  list  provides  a  record  of  the  last  3  Data  Link  messages  wilcoed  by  an  aircraft.  The  first  line 
of  the  list  contains  the  ACID  of  the  subject  aircraft,  while  the  remaining  lines  display  the  messages 
received.  Messages  are  automatically  sent  to  the  history  list  when  the  wilco  is  received. 


-  Message  Content  Display 

In  general,  the  content  of  messages  represented  in  the  history  list  is  displayed  with  nininal  use  of 
abbreviations  (e.g.  FLY  HDG  150).  However,  when  a  single  nessage  contains  multiple  semi  text  clearances  or 
a  teninal  information  nessage  conbined  with  a  menu  text  clearance,  alternate  representations  are  used  to 
conserve  display  space.  If  a  TI  message  is  conbined  with  an  HT  nessage,  the  content  of  the  clearance 
portion  of  the  nessage  is  abbreviated  using  the  shorthand  fora  used  in  the  status  list  and  data  block 
displays.  In  this  case,  the  TI  portion  of  the  nessage  is  displayed  on  one  line  and  the  HT  clearance  is 
presented  on  the  following  line  preceded  by  three  periods  to  indicate  that  the  clearance  was  appended  to  the 
TI  (e.g.  "TI  nessage" 

"...A060") 

When  nultiple  MT  clearances  are  included  in  a  nessage  they  are  displayed  in  the  shorthand  fora  on  a  single 
line  of  the  history  list  separated  by  spaces  (e.g.  "H150  A060  V15"). 


-  Message  Order 

The  messages  are  listed  in  reverse  chronological  order  of  receipt,  with  the  most  recently  received  nessage 
appearing  at  the  bottom  of  the  list.  The  list  scrolls  up  as  new  messages  are  received. 


-  Inputs  to  Display  History  List 

The  history  list  for  an  aircraft  can  be  viewed  by  entering  "HL"  and  SLEW. 


-  Location  of  History  List 

The  history  list  replaces  the  status  list.  The  history  list  remains  in  this  position  for  8  seconds  after  it 
is  selected  and  is  then  replaced  by  the  status  list.  Alternatively,  reentering  the  "HL"  SLEW  command  for 
the  same  aircraft  will  manually  remove  the  history  list. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  History  List  that  you  examined  in  the  Test 
Bed? 


YES,  THE  DESCRIPTION  IS  CORRECT 
NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  Will  3  messages  for  each  aircraft  provide  a  sufficient  record 
of  past  transactions  in  the  History  List?  If  not,  how  many 
will  be  needed? 


3.  In  the  current  design,  abbreviated  text  is  used  for  displaying 
TI  and  MT  transactions  when  a  single  message  was  sent.  To 
deal  with  space  limitations,  the  system  reverts  to  displaying 
the  MT  message (s)  in  the  shorthand  form  when  a  TI  and  an  MT, 
or  multiple  MT  clearances  were  sent  in  a  single  message  —  Is 
this  preferred,  or  should  MT  messages  be  presented 
consistently  in  the  shorthand  form  for  all  situations? 


4.  In  the  current  design,  the  History  List  shares  locations  with 
the  Status  List.  Is  this  preferable  to  overlaying  the  MT/TI 
list  as  in  earlier  designs? 
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5.  Is  the  8  second  display  time  (with  an  ability  to  suppress  the 
display  earlier)  adequate  for  the  History  List? 


6.  What  should  be  done  to  improve  the  design  of  the  History  List? 
Include  any  changes  suggested  by  your  answers  to  questions 
2 .  -  5 .  above . 


THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 
CHANGES  ARE  DESIRABLE  OR  NEEDED 

THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 
CHANGES  ARE  NEEDED,  BUT  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  -- 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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INITIAL  CONTACT  (IC) 

SERVICE  DESCRIPTION: 


-  Initiation  of  IC 

The  IC  is  initiated  when  the  aircraft  pilot  responds  with  a  WILCO  nessage  to  a  preceding  transfer  of 
comunication.  The  aircraft's  assigned  altitude  is  appended  to  the  WILCO  downlink  response,  and  this  value 
is  sent  via  interfacility  or  intrafacility  data  channels  to  the  receiving  control  position. 

If  the  aircraft  fails  to  append  the  assigned  altitude  to  the  TOC  wilco,  the  systee  automatically  sends  an 
altitude  request  { AR)  nessage  to  the  aircraft.  The  ongoing  status  of  this  transaction  is  displayed  in  the 
receiving  controller's  status  list  and  data  block.  An  AU  is  also  autonatically  sent  to  departing  aircraft 
in  order  to  initiate  the  IC  for  first  contact. 


-  Display  on  Downlink  of  Assigned  Altitude 

When  the  aircraft  downlinks  its  assigned  altitude  with  the  wilco  to  the  TOC  or  in  response  to  an  AS,  the 
third  line  of  the  data  block  displays  the  characters  "IC"  followed  by  the  3-digit  altitude  value  (e.g.  "IC 
110").  The  third  line  of  the  Data  Block  flashes  to  capture  the  controller's  attention  and  signal  a  required 
response. 


-  Response  to  an  IC  Downlink 

The  controller  response  nay  be  a  TI  message,  initiation  of  a  transfer  of  communication,  one  or  more  menu 
text  messages,  or  a  combination  of  a  TI  nessage  and  an  KT  message.  Initiation  of  the  uplink  immediately 
deletes  the  "IC"  display  in  the  third  line  of  the  data  block. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 

operation  of  the  Initial  Contact  service  that  you  examined  in 
the  Test  Bed? 


YES,  THE  DESCRIPTION  IS  CORRECT 
NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  ot  the  description  that 
did  not  match  your  observations  — 


2.  The  major  change  to  the  IC  included  in  this  implementation 
was  made  to  eliminate  the  delay  associated  with  the  uplinked 
altitude  request  and  IC  downlink.  In  the  current  design,  the 
assigned  altitude  is  downlinked  with  the  Wilco  to  the 
Transfer  of  Communication.  Is  this  change  acceptable?  Do 
you  foresee  any  potential  operational  problems  with  the 
procedure? 


3.  The  altitude  request  (AR)  uplink  is  used  in  the  present  design 
to  deal  with  first  contact  departures  and  aircraft  that  do  not 
append  the  assigned  altitude  to  the  TOC  wilco.  Is  this 
procedure  acceptable?  Do  you  foresee  any  potential 
operational  problems? 


4.  Is  the  flashing  IC  display  in  the  Data  Block  adequate  to 
capture  the  controller's  attention  when  the  altitude  is 
downlinked? 
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5-  Are  the  TI ,  MT,  and  combination  uplink  options  sufficient  to 
cover  all  operational  requirements  for  responses  to  the  IC? 
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6.  What  should  be  done  to  improve  the  design  of  the  Initial 
Contact  service  ?  Include  any  changes  suggested  by  your 
answers  to  questions  2.  -  5.  above. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  NEEDED,  BUT  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  — 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 


B-15 


16 


TERMINAL  INFORMATION  SERVICE  (TI) 
SERVICE  DESCRIPTION: 


-  Initiation  of  TI 

A  nessage  in  the  TI  list  can  be  sent  at  any  tine  through  a  controller  input  action.  When  used  iinediately 
after  receiving  an  initial  contact  nessage  fron  an  aircraft  ("IC"  and  an  altitude  value  displayed  in  the 
third  line  of  the  data  block)  a  slew  input  can  be  used  to  send  a  connonly-used  default  TI  nessage. 


-  TI  List  Display 

TI  nessages  are  selected  fron  a  list  display  with  the  header  "TI"  at  the  top  and  containing  four  optional 
aessages.  Each  nessage  is  preceded  by  an  identifier  letter  (A  -  D).  The  nessage  appearing  on  the  first  line 
(regardless  of  its  identifier  letter)  is  the  default  nessage.  Each  of  the  nessages  can  be  up  to  40 
characters  long. 


-  Inputs  to  Change  Default  Message 

The  default  nessage  can  be  changed  by  pressing  the  D/L  key  followed  by  "D",  the  identifying  letter  of  the 
new  iten  desired  (A  to  D),  and  ENTER.  This  action  will  nove  the  selected  iten  to  the  first  line  of  the  list 
and  rearrange  the  renaining  itens  in  alphabetic  order  of  their  identifier  letters.  Itens  always  retain 
their  original  identifier  letters  regardless  of  the  iten  designated  as  the  default  nessage.  Changing  the 
default  nessage  autonatically  restores  any  suppressed  itens  to  the  TI  list  (see  suppressing  individual  TI 
nessages  below). 


-  Inputs  to  Reposition  TI  List 

The  TI  list  can  be  noved  independently  to  any  position  on  the  ARTS  display  by  pressing  the  F8  key,  typing 
"T"  and  SLEW  to  position  the  list. 


-  Inputs  to  Suppress  /  Retrieve  TI  List 

The  entire  TI  list  can  be  renoved  fron  the  ARTS  display  by  pressing  the  D/L  key,  typing  "T"  and  ENTER. 
Repeating  this  sequence  will  retrieve  the  list. 


-  Suppressing  Display  of  Individual  TI  Messages 

If  desired,  fewer  than  4  TI  nessages  can  be  displayed  in  the  list.  Pressing  the  D/L  key  followed  by  the 
iten  identifier  letter  and  ENTER  renoves  the  selected  iten  fron  the  list  display.  All  other  itens  naintain 
their  original  letter  identifiers,  and  the  suppressed  iten  renains  available  for  uplink  by  the  nomal  data 
entries.  Iteis  can  be  retrieved  to  the  list  display  by  repeating  the  D/L  key  -  iten  identifier  entry.  If 
all  itens  in  the  list  are  individually  suppressed,  the  "TI"  header  renains  on  the  display  to  indicate  the 
suppressed  list  location  and  to  renind  the  controller  that  restoring  the  list  will  require  individual 
entries  rather  than  the  entry  used  to  retrieve  the  entire  list  if  it  had  been  suppressed  using  the  F9T 
entry. 
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Changing  the  default  message  in  the  TI  list  will  automatically  restore  all  individually  suppressed  items  to 
the  list. 


-  Inputs  to  Send  Default  TI  After  IC 

When  a  successful  initial  contact  has  been  completed  and  the  third  line  of  the  data  block  displays  "IC" 
followed  by  an  altitude  value,  the  default  TI  message  may  be  uplinked  by  a  SLEW  action. 

-  Inputs  to  Send  TI  Messages  at  Any  Time 

Messages  can  be  uplinked  at  any  time  by  typing  "T",  the  message  identifier  letter  from  the  TI  list  (e.g. 
"B")  and  SLEW. 


-  Displays  on  TI  Uplink 

If  a  TI  message  is  sent  when  "IC"  and  an  altitude  value  are  shown  in  the  third  line  of  the  data  block,  the 
entry  deletes  the  "IC"  and  altitude,  and  replaces  it  with  "TI*"  followed  by  the  message  letter  selected  from 
the  list  for  uplink.  The  status  list  entry  displays  the  identical  message. 


-  Displays  After  Pilot  WILCO 

Upon  receipt  of  a  downlinked  WILCO  response  from  the  aircraft,  the  "Tl"/message  letter  display  in  the  third 
line  of  the  data  block  is  deleted.  WIL  is  displayed  in  the  status  list  entry  for  8  seconds  before  the  entry 
is  deleted. 


-  Combining  TI  with  an  HT  Message 

Any  TI  message  can  be  sent  together  with  one  KT  message  by  typing  "T"  and  the  TI  message  letter  desired 
prior  to  the  Menu  Text  entry  (e.g.  "TDH4").  The  multiple  KT  message  displayed  on  line  9  of  the  HT  list 
cannot  be  combined  with  a  TI  message.  The  default  TI  message  can  be  sent  with  a  Menu  Text  message  without 
specifying  the  TI  message  number  (e.g.  "TH4")  if  the  IC  message  is  flashing  in  the  Data  Block. 


-  Changing  the  Content  of  TI  Messages 

The  content  of  any  of  the  four  TI  messages  can  be  changed  by  pressing  the  D/L  key,  "T",  and  the  identifier 
letter  of  the  message  to  be  changed.  These  entries  are  followed  by  a  space,  the  desired  text  message,  and 
ENTER  (e.g.  "F9TB  text  messageENTER").  The  text  message  may  be  up  to  40  characters  long. 


B-17 


18 


REVIEW  QUESTIONS 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Terminal  Information  service  that  you 
examined  in  the  Test  Bed? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 

_  NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  In  the  current  design,  each  of  the  four  TI  messages  can  be 
displayed  with  a  maximum  of  40  characters.  Will  these 
increased  message  lengths  be  sufficient  for  operational 
application? 


3.  The  TI  message  identifiers  have  been  changed  to  alphabetic 
letters  rather  than  numerals  for  the  current  implementation. 
Does  this  change  adversely  affect  the  ease  with  which  messages 
can  be  selected  from  the  list  or  the  interpretation  of  status 
displays?  If  so,  in  what  way? 


4 . 


The  TI  list  can  now  be  suppressed  and  moved  independently  from 
the  MT  list.  Is  this  feature  useful?  Why  or  why  not? 
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5.  It  is  now  possible  to  suppress  individual  items  on  the  TI 
list.  Is  this  feature  useful?  Why  or  why  not? 


6.  Does  the  design  offer  sufficient  flexibility  for  combining  TI 
and  MT  messages? 


7.  What  should  be  done  to  improve  the  design  of  the  Terminal 
Information  service  ?  Include  any  changes  suggested  by  your 
answers  to  questions  2 .  -  5 .  above . 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  NEEDED,  BUI  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  - 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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TRANSFER  OF  COMMUNICATIONS  (TOC) 

SERVICE  DESCRIPTION: 


-  Initiation  of  TOC 

The  TOC  message  containing  a  new  radio  frequency  for  an  aircraft  is  automatically  prepared  when  the 
receiving  controller  accepts  a  sector  hand  off. 


-  TOC  lode  Display 

TOC  can  be  set  to  operate  in  either  an  automatic  send  or  manual  send  »ode.  The  active  TOC  node  is  displayed 
in  the  Systems  Data  Area  (SDA).  "TC  HOLD"  is  displayed  when  the  systei  is  in  the  nanual  send  node  and  "TC 
SEHD"  is  displayed  when  the  systei  is  in  the  automatic  send  K>de.  When  the  ARTS  prograi  is  started,  TOC  is 
in  the  nanual  or  hold  «ode.  Pressing  the  D/L  key,  "TH"  and  ENTER  will  change  TOC  to  the  auto»atic  iode  and 
cause  the  node  display  to  change  to  "TC  SEHD".  Repeating  the  sa»e  entry  will  switch  the  iode  back  to  "TC 
HOLD" 

-  Inputs  to  Send  TOC  -  TC  SEND  lode 

If  in  the  TC  SEHD  iode,  the  TOC  is  automatically  uplinked  upon  acceptance  of  the  hand  off  when  the  sending 
controller  completes  the  normal  keyboard  sequence  for  hand  off  initiation  (HAHDOFF  key  (F5),  the  receiving 
sector's  Controller  Symbol,  and  SLEW).  Any  other  currently  acceptable  ARTS  input  sequence  normally  used  to 
initiate  a  hand  of.5  will  result  in  the  same  automatic  uplink  of  TOC  (e.g.  P5-ACID-Controller  Symbol-  ENTER). 


-  Display  on  TC  SEHD  TOC  Oplink 

"TC"  is  displayed  in  the  third  line  of  the  data  block  and  in  the  status  list  when  the  TOC  message  is 
uplinked. 


-  Inputs  to  Hold  a  Message  When  in  TC  SEHD  lode 

When  in  the  TC  SEND  Hode,  the  TOC  can  be  held  for  delayed  uplink  by  adding  an  "H"  prior  to  the  SLEW  entry 
for  the  Handoff  (i.e.  "F5,  Controller  Symbol,  H,  SLEW").  The  system  will  revert  to  the  TC  SEND  mode  for 
succeeding  TOCs  unless  the  node  is  changed  or  the  "H"  is  again  added  to  the  handoff  entry. 


-  Inputs  to  Send  TOC  -  TC  HOLD  lode 

When  in  the  TC  HOLD  mode,  the  controller  may  initiate  the  sector  hand  off  but  reserve  communications 
eligibility  until  a  later  time  by  completing  the  normal  keyboard  sequence  for  hand  off  initiation  (HANDOFF 
key  (F5),  the  receiving  sector's  Controller  Symbol,  and  SLEW).  Any  other  currently  acceptable  ARTS  input 
sequence  normally  used  to  initiate  a  hand  off  will  result  in  the  same  held  states  of  TOC  (e.g.  F5-ACID- 
Controller  Symbol-  ENTER).  The  TOC  can  then  be  sent  manually  by  a  SLEW  action. 
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-  Display  on  Manual  (TC  HOLD)  Uplink 

"TC  H"  is  displayed  in  the  third  line  of  the  sending  sector's  data  block  when  a  handoff  has  been  completed 
in  the  hold  mode.  "SNT"  and  succeeding  transaction  states  are  displayed  in  the  status  lists  of  both  the 
sending  and  receiving  sectors  when  the  SLEW  is  completed  to  manually  send  the  TOC. 


-  Inputs  to  Automatically  Send  TOC  When  in  TC  HOLD  lode 

When  in  the  TC  HOLD  Mode,  the  TOC  can  be  sent  autonatically  upon  handoff  acceptance  by  adding  an  "S"  prior 
to  the  SLEW  entry  for  the  hand  off  (i.e.  F5,  Controller  Symbol,  S,  SLEW).  The  systen  will  revert  to  the  TC 
HOLD  node  for  succeeding  TOCs  unless  the  node  is  changed  or  the  "S"  is  again  added  to  the  hand  off  entry. 


-  Display  After  Pilot  WILCO 

In  both  automatic  and  manual  procedures  the  "TC"  display  in  the  third  line  of  the  data  block  is  deleted  when 
the  aircraft  downlinks  a  WILCO  response.  The  status  list  entry  will  display  "WIL"  for  8  seconds  after 
receipt  of  the  wilco,  and  then  will  be  deleted. 


-  Sending  Other  Messages  When  a  TOC  is  in  Held  Status 

An  MT  or  TI  nessage  can  be  sent  to  the  aircraft  while  a  TOC  is  in  the  held  status.  Sending  the  new  message 
will  replace  the  "TC  H"  display  in  the  data  block  with  the  type,  identifier  and  status  of  the  TI  or  HT 
message.  When  the  message  is  wilcoed,  the  "TC  H"  reappears  in  the  data  block. 


-  Offering  a  Hand  Off  While  a  Data  Link  Transaction  is  in 
Progress 

If  a  Data  Link  transaction  is  in  progress  when  the  sending  controller  wishes  to  hand  off  to  another  sector, 
the  normal  hand  off  entries  will  be  accepted  by  the  ARTS  computer,  and  the  hand  off  can  be  accepted  by  the 
receiving  controller.  The  ongoing  message  status  will  continue  to  be  displayed  in  the  data  block  until  it 
is  wilcoed  or  until  the  controller  enters  the  message  delete  command.  The  TOC  message  will  then  be 
automatically  sent  if  1)  the  handoff  has  been  accepted  and  2)  the  system  is  set  to  the  TC  SEND  mode  or  the 
controller  added  the  "S"  keystroke  to  the  hand  off  entry  in  the  TC  HOLD  Node. 

If  the  handoff  is  accepted  and  the  system  is  in  the  TC  HOLD  mode  or  the  controller  added  the  "H"  keystroke 
to  the  hand  off  entry  in  the  TC  SEND  mode,  the  wilco  or  deletion  of  the  prior  transaction  will  cause  the  TC 
H  display  to  appear  in  the  data  block,  and  the  TOC  will  be  sent  when  the  SLEW  is  completed.  In  all  cases, 
the  receiving  controller's  status  list  (but  not  data  block)  will  show  the  TOC  status  when  the  TOC  message  is 
sent. 


-  Inputs  to  Acquire  Data  Link  Eligibility 

The  controller  may  acquire  ("steal")  eligibility  for  Data  Link  communications  by  pressing  the  D/L  key, 
typing  the  letters  "OK"  and  a  SLEW  action.  This  action  also  sends  a  TOC  message  to  the  aircraft. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Transfer  of  Communication  service  that  you 
examined  in  the  Test  Bed? 

_  YES,  THE  DESCRIPTION  IS  CORRECT 

_  NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  The  active  mode  for  the  TOC  is  now  displayed  in  the  Systems 
Data  Area  and  defaults  to  "TC  HOLD”  on  system  start-up.  Are 
these  changes  preferable  to  the  earlier  approach  of  displaying 
the  mode  at  the  top  of  the  status  list  and  defaulting  to  ”TC” 
SEND”?  Would  some  other  approach  be  better? 


3.  In  the  current  design,  it  is  possible  to  offer  a  hand  off  and 
have  it  accepted  by  the  receiving  controller  while  a  Data  Link 
transaction  is  in  progress.  Are  the  resulting  Data  Block 
display  and  sequence  of  events  for  accomplishing  the  TOC  after 
the  completion  of  the  prior  transaction  acceptable?  If  not, 
why? 
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4.  The  receiving  sector's  Data  Block  no  longer  displays 
information  about  the  TOC  transaction  being  completed 
by  the  sending  controller.  Is  this  change  desirable? 
Why  or  why  not? 


5.  What  should  be  done  to  improve  the  design  of  the  Transfer  of 
Communication  service?  Include  any  changes  suggested  by  your 
answers  to  questions  2.  -  4.  above. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  NEEDED,  BUT  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  — 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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SERVICE  DESCRIPTION; 


MENU  TEXT  (MT) 


-  Function 

The  HT  service  penits  the  controller  to  uplink  speed,  heading  and  altitude  clearances  by  selecting  the 
required  messages  fro*  a  predefined  nenu  or  by  coiposing  clearances  not  contained  in  the  lenu. 


-  IT  List  Display 

Available  MT  clearances  are  displayed  in  a  list  containing  9  lines.  Each  *enu  iten  is  displayed  on  a  single 
line  preceded  by  an  identifier  nuiber  (1-9).  Messages  are  selected  using  the  identifier  nuibers. 

The  first  8  lines  are  dedicated  to  specific  clearance  types.  Lines  1,  2  and  3  are  for  heading  clearances  and 
are  preceded  by  the  header  "HDG".  Lines  4,  5  and  6  are  reserved  for  altitudes  and  are  preceded  by  the 
header  "ALT".  Lines  7  and  8  are  for  speed  control  and  are  preceded  by  the  header  "VEL".  Line  9  is  preceded 
by  the  header  "MOLT",  and  is  used  for  a  Multiple  entry  composed  of  any  two  or  three  ite«s  contained  in  lines 
1  to  8.  Only  one  of  each  clearance  type  lay  be  entered  on  line  9. 


-  MT  List  Ite*  Content 

The  content  of  each  of  the  three  clearance  types  is  highly  structured,  and  autoiation  is  used  to  produce  a 
complete  nessage  froi  the  structured  data.  In  each  case,  clearances  are  displayed  in  the  »enu  as  a 
nunerical  value  followed  by  "DEG",  "FT*,  or  "KTS”.  Hie  direction  of  an  altitude  change  (descend  or  cliib) 
is  added  by  the  autoiation  when  the  Message  is  sent  by  coiparing  the  aircraft's  current  altitude  with  the 
Message  data.  The  "increase"  or  "decrease"  conands  are  added  to  a  velocity  Message  in  a  siiilar  Manner. 
Heading  clearances  are  sent  as  "Fly  Heading.."  unless  a  special  cooand  is  added  to  the  Menu  selection  as 
described  below.  The  line  9  Multiple  clearance  is  displayed  by  the  relevant  iten  identifier  nuibers 
separated  by  slashes  (e.g.  "1/5/8"). 


-  Inputs  to  Send  a  MT  Message 

A  single  MT  itei  can  be  uplinked  by  typing  "M"  followed  by  the  nenu  iten  identifier  nunber,  and  a  SLEW 
action. 


-  Controlling  the  Direction  of  a  Turn  in  a  Heading  Clearance 

The  specific  direction  of  a  turn  can  be  included  in  a  heading  nessage  contained  in  the  nenu  by  typing  an  "L" 
or  "II"  after  the  nenu  identifier  nuiber  (e.g.  "MIR  SLEW). 


-  Inputs  to  Reposition  MT  List 

The  position  of  the  MT  list  on  the  ARTS  display  can  be  independently  changed  by  pressing  the  F8  key,  typing 
"M",  and  coipleting  a  SLEW  action  to  love  the  list. 
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-  Inputs  to  Suppress  /  Retrieve  NT  List 

The  entire  MT  list  can  be  renoved  fron  the  display  by  pressing  the  D/l  key  and  typing  *M*  and  ESTER.  The 
list  is  retrieved  using  the  sane  sequence  of  key  strokes. 


-  Suppressing  Display  of  Individual  KT  Messages 

If  desired,  fewer  than  9  MT  nessages  can  be  displayed  in  the  list.  Pressing  the  D/L  key  followed  by  the 
iten  identifier  nunber  and  ENTER  renoves  the  selected  iten  froi  the  list  display.  All  other  iteis  Maintain 
their  original  nunber  identifiers,  and  the  suppressed  itei  renains  available  for  uplink  by  the  noraal  data 
entries.  Itens  can  be  retrieved  to  the  list  display  by  repeating  the  D/L  key  -  itei  identifier  entry.  If 
all  itens  in  a  particular  category  (HDG,  ALT,  VEL,  MDLT)  are  suppressed,  the  category  header  also  will  be 
suppressed.  If  all  itens  in  the  list  are  individually  suppressed,  the  "MT"  header  regains  on  the  display  to 
indicate  the  suppressed  list  location  and  to  rewind  the  controller  that  restoring  the  list  will  require 
individual  entries  rather  than  the  entry  used  to  retrieve  the  entire  list  if  it  had  been  suppressed  using 
the  F9M  entry. 


-  Inputs  to  Send  Multiple  MT  Messages 

Op  to  three  MT  Menu  iteMS  can  be  sent  in  a  single  uplink  by  inserting  spaces  between  the  iten  nunbers.  (e.g. 
Ml  4  8  SLEW  would  send  Menu  itens  1,  4  and  8).  Iten  9  cannot  be  conbined  with  other  itens.  The  software 
will  not  pemit  attenpts  to  send  nore  than  one  of  each  clearance  type  (altitude,  heading  or  altitude)  in  a 
Multiple  nenu  uplink. 


-  Bypassing  the  Menu 

A  heading  (H),  altitude  (A)  or  velocity  (V)  not  contained  in  the  nenu  can  be  uplinked  by  pressing  the  D/L 
key,  typing  "H",  "A"  or  "V"  followed  by  the  miner ic  value  of  the  clearance  and  SLEW.  One  of  each  clearance 
type  also  can  be  conbined  in  a  single  uplink  in  any  order  (e.g.  "F9H230A030").  The  third  line  of  the  data 
block  and  the  status  list  entry  display  the  clearance  letters,  and  the  nunerical  values  entered  (e.g. "A 
110")  until  the  Message  is  wilcoed.  The  direction  of  a  turn  for  a  heading  clearance  can  be  controlled  by 
substituting  "L"  or  "R"  for  "H"  in  the  data  entry. 


-  Inputs  to  Send  an  MT  Message  Conbined  with  TI 

A  TI  nessage  can  be  sent  in  conbination  with  one  MT  iten  by  adding  "T"  and  the  desired  TI  Message  nunber 
prior  to  the  first  MT  input  (e.g.  TDK3  SLEW  would  send  TI  nessage  D  and  nenu  iten  3).  The  default  TI 
Message  can  be  conbined  with  an  MT  nessage  without  specifying  the  default's  identifier  nunber  (e.g.  TN3 
SLEW)  if  the  IC  nessage  is  flashing  in  the  Data  Block. 


-  Displays  on  MT  Dpi  ink 

when  an  MT  or  By-pass  uplink  is  initiated,  the  third  line  of  the  data  block  and  the  associated  status  list 
line  displays  a  shorthand  abbreviation  of  the  nessage  content  (e.g.  "H230A030") 
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-  Displays  After  Pilot  WILOO 

A  downlinked  WILCO  to  an  JET  nessage  or  group  of  messages  deletes  the  data  in  the  third  line  of  the  data 
block  and  causes  "MIL"  to  be  displayed  in  the  status  list  for  8  seconds. 


-  Modifying  Mtaeric  Values  in  Menu  Itens 

The  nuneric  value  of  a  heading,  speed  or  altitude  clearance  can  be  changed  by  pressing  the  D/L  key,  typing  H 
and  the  one-digit  identifier  nunber  of  the  nenu  ite«  to  be  changed,  typing  the  new  miner ic  value  and 
pressing  the  ENTER  key  (e.g.  "P9H3060"). 

If  a  SLEW  action  is  substituted  for  the  keyboard  ENTER,  the  lenu  itei  will  be  changed  AND  the  nessage  will 
be  uplinked  to  the  slewed  aircraft.  For  heading  clearances,  if  "L"  or  "R"  is  appended  to  the  entry  prior  to 
the  SLEW  (e.g.  "F9K3060L" )  the  directional  turn  clearance  will  be  uplinked  (e.g.  "Turn  Left  Heading  060"), 
but  the  nodified  nenu  iten  will  contain  the  generic  heading  nessage  for  future  use  (e.g.  "Fly  Heading  060"). 
In  all  cases,  nodified  values  will  stay  in  the  NT  list  entries  until  they  are  changed  again  or  the  progran 
is  restarted. 


-  Creating/Modifying  Line  9  Coubination  Clearance 

Line  9  pemits  the  conbination  of  up  to  three  clearances  shown  in  lines  1  to  8.  This  entry  is  created  or 
nodified  by  pressing  the  D/L  key,  typing  "H9",  the  identifier  nunbers  for  two  or  three  of  entries  1  to  8  and 
ENTER.  If  a  SLEW  action  is  substituted  for  ENTER,  the  conbined  clearance  will  be  entered  in  the  list  and 
sinultaneously  sent  to  the  designated  aircraft. 
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REVIEW  QUESTIONS: 

1.  Does  the  description  accurately  represent  the  design  and 
operation  of  the  Menu  Text  service  that  you  examined  in  the 
Test  Bed? 


YES,  THE  DESCRIPTION  IS  CORRECT 
NO,  IT  DOESN'T  MATCH 

Describe  those  aspects  of  the  description  that 
did  not  match  your  observations  — 


2.  The  letter  used  to  prefix  speed  clearances  composed  with  the 
Menu  Bypass  feature  was  changed  from  "S"  to  "VM  (velocity)  in 
order  to  locate  all  three  prefix  letters  ("A",  "H" ,  and  "V" ) 
in  the  same  column  on  the  ARTS  keyboard.  Is  this  change 
acceptable?  Will  it  simplify  the  task  of  composing  bypass 
messages? 


3.  The  current  menu  design  has  added  headers  (HDG ,  ALT,  VEL, 
MULT)  to  each  category  of  clearance.  Does  this  modification 
help  when  selecting  items  from  the  menu? 
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4.  The  current  menu  design  displays  general  heading,  altitude 
and  velocity  values  that  are  interpreted  by  the  automation  to 
generate  the  appropriate  message  for  uplink  (e.g.  "climb  and 
maintain"  when  the  aircraft's  altitude  is  lower  than  that 
shown  in  the  display).  Does  this  change  improve  the 
flexibility  and  usability  of  the  menu? 


5.  Is  the  procedure  used  for  controlling  the  turn  direction  (L  or 
R)  in  a  heading  menu  text  uplink  acceptable? 


6.  The  MT  list  can  now  be  suppressed  and  moved  independently  from 
the  TI  list.  Is  this  feature  useful?  why  or  why  not? 


7 .  It  is  now  possible  to  suppress  individual  items  on  the  MT 
list.  Is  this  feature  useful?  Why  or  why  not? 
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8.  What  should  be  done  to  improve  the  design  of  the  Menu  Text 
service?  Include  any  changes  suggested  by  your 
answers  to  questions  2.  -  6.  above. 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  DESIRABLE  OR  NEEDED 

_  THE  CURRENT  IMPLEMENTATION  IS  ACCEPTABLE  —  NO 

CHANGES  ARE  NEEDED,  BUI  THE  FOLLOWING  WOULD  BE 
DESIRABLE:  (describe) 


THE  CURRENT  IMPLEMENTATION  IS  UNACCEPTABLE  — 
THE  FOLLOWING  CHANGES  MUST  BE  MADE: 
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GENERAL  DESIGN  OF  MENU  LISTS 

Over  the  course  of  the  effort  to  design  terminal  Data  Link  ATC 
services,  several  modifications  have  been  made  to  the  TI  and  MT 
lists  which  permit  the  controller  to  minimize  keyboard  entries  by 
selecting  messages  from  menus.  However,  a  number  issues 
regarding  the  design  and  application  of  these  menu  lists  remain 
unresolved.  The  intent  of  the  following  questions  is  to  solicit 
your  inputs  on  1)  the  operational  requirements  for  the  menu  used 
to  send  control  clearances  (MT)  and  2)  design  features  needed  to 
minimize  errors  and  maximize  the  controller's  ability  to  use  the 
menus  effectively. 


STRUCTURED  VS.  FREE  TEXT  MENU  ITEMS 

The  current  design  of  the  MT  list  is  one  example  of  a  structured 
menu.  Menu  lines  are  assigned  to  specific  clearance  types  and 
the  content  is  highly  standardized.  The  main  advantages  of  this 
approach  to  menu  design  are  that  it  allows  extensive  use  of 
automation  to  construct  the  uplinked  message,  and  that  it  offers 
much  more  compact  and  efficient  coding  of  the  clearance  for 
transmission  over  the  Data  Link  than  if  the  message  were  sent  as 
free  text.  The  limitation  of  a  structured  system  is  that  it  may 
be  too  inflexible  to  represent  all  messages  that  a  controller 
might  want  to  send. 

Conversely,  the  free  text  approach  (like  that  adopted  for  the  TI 
list)  provides  high  flexibility  in  the  menu,  but  is  an 
inefficient  way  to  send  all  messages  over  the  Data  Link. 

Thus  far,  the  terminal  design  for  MT  has  progressively  added 
several  design  features  under  a  structured  approach  which  are 
intended  to  increase  the  flexibility  of  the  menu: 

-  Menu  lines  dedicated  to  speed,  heading  and  altitude  clearances 
which  can  be  modified  by  the  controller 

-  Capability  to  combine  individual  speed,  heading,  and  altitude 
menu  lines  in  a  single  uplink 

-  Capability  to  create  a  special  multiple  clearance  item  (Line  9) 

-  The  menu  by-pass  feature  for  composing  clearances  in  shorthand 
form  in  real  time 

-  Generic  clearance  messages  with  automatic  determination  of 
climb/descend  and  increase/decrease,  plus  the  ability  to 
control  turn  direction 

-  Capability  to  combine  a  TI  item  with  an  MT  item  in  a  single 
message 
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Do  you  feel  that  the  current  Menu  Text  design  with  these  options 
will  be  sufficient  for  generating  the  control  clearance  messages 
that  will  be  sent  via  Data  Link  in  the  operational  terminal 
environment? 


Yes,  the  current  design  is  sufficiently  flexible 


No,  the  entire  menu  must  be  changed  to  the  free  text 
format  to  provide  sufficient  flexibility 


No,  the  structured  menu  should  be  maintained,  but  one 
or  more  optional  free  text  menu  items  must  be  added 


No,  the  following  additions  /  changes  must  be  made  to 
make  the  system  sufficiently  flexible: 


Regardless  of  vour  answer,  please  add  any  comments  that  you  may 
have  regarding  the  design  of  the  MT  menu: 
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FEATURES  RELATED  TO  CONTROLLER  PERFORMANCE  AND  ERROR 

In  addition  to  the  issue  of  menu  structuring,  several  features  of 
the  design  for  the  menu  lists  have  been  added  to  minimize 
controller  keyboard  entry  errors  and  to  simplify  the  task  of 
searching  for  and  selecting  menu  items. 


Rate  each  of  the  design  features  shown  below  in  terms  of  the 
extent  to  which  you  feel  it  will  enhance  or  impair  controller 
performance  when  using  the  menus.  Place  an  "x"  on  the  line  to 
indicate  your  rating: 


1.  The  TI  list  and  MT  list  are  distinguished  by  their 

applications.  The  TI  menu  may  contain  only  informational 
messages,  while  the  MT  list  is  reserved  for  control 
clearances . 


+3 

+2 

+1 

0  -1 

-2 

-3 

I 

I 

I 

I  I 

I 

I 

Very 

No  Effect 

Very 

Positive 

On  Errors  Or 

Negative 

Effect 

Performance 

Effect 

2.  To  reduce  inadvertent  selection  of  items  from  the  unintended 
list,  letters  are  used  as  item  identifiers  for  TI  messages  and 
numbers  are  used  as  item  identifiers  for  MT  messages. 


+3 

+2 

+1 

0  -1 

-2 

-3 

I 

I 

I 

I  I 

I 

I 

Very 

No  Effect 

Very 

Positive 

On  Errors  Or 

Negative 

Effect 

Performance 

Effect 

3.  Headers  (or  Spaces)  are  used  to  help  in  locating  the  desired 
category  of  clearances  in  a  group  of  messages  contained  on  the 
MT  list. 


+  3  +2  +1  0  -1  -2  -3 

I _ I _ I _ I _ I _ I _ I 


Very  No  Effect  Very 

Positive  On  Errors  Or  Negative 

Effect  Performance  Effect 
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4.  Unused  TI  items  and  MT  items  can  be  individually  suppressed  to 
reduce  list  length  and  clutter. 

+  3  +2  +1  0  -1  -2  “3 

I _ I _ I _ I _ I _ I _ I 


Very 

Positive 

Effect 


No  Effect 
On  Errors  Or 
Performance 


Very 

Negative 

Effect 


5.  The  entire  TI  list  and/or  MT  list  can  be  suppressed  to  reduce 
clutter . 

+3  +2  +1  0  -1  -2  -3 

I _ I _ I _ I _ I _ I _ I 


Very 

Positive 

Effect 


No  Effect 
On  Errors  Or 
Performance 


Very 

Negative 

Effect 


6.  The  TI  list  and  MT  list  are  independently  movable  to  minimize 
visual  scanning  requirements. 

+3  +2  +1  0  -1  -2  -3 

I _ I _ I _ I _ I _ I _ I 


Very 

Positive 

Effect 


No  Effect 
On  Errors  Or 
Performance 


Very 

Negative 

Effect 


7.  The  key  entries  used  to  prefix  MT  clearances  (H,  A,  V)  are  in 
a  single  column  on  the  ARTS  keyboard  and  in  the  same  spatial 
order  as  displayed  in  the  menu  to  simplify  menu  item 
selection. 


+  3 

+  2 

+1 

0  -1 

-2 

-3 

I 

I 

I 

I  I 

I 

I 

Very 

No  Effect 

Very 

Positive 

On  Errors  Or 

Negative 

Effect 

Performance 

Effect 

Please  use  the  next  page  to  add  any  other  features  that  you  feel 
may  enhance  controller  performance  when  using  the  menus 
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APPENDIX  C 


STRATEGY  ASSESSMENT  MATERIALS 


Arrival/Final 
Test  Run  Questionnaire 

DATA  LINK  -  2  CONTROLLERS 


Run 


Controller 


Assistant 


—  Please  complete  this  questionnaire  as  a  team.  If  you  do  not 
a crree  on  an  answer,  record  both  views. 

1.  Briefly  describe  the  sequence  of  clearances  that  you  used  to 
control  the  traffic  presented  in  this  scenario.  Include  any 
strategies  that  you  may  have  developed  to  efficiently  move  the 
arriving  aircraft  onto  the  final  approach.  (If  this  is  not  your 
first  test  run  under  "Data  Link  with  two  controllers",  describe 
only  those  changes  that  you  made  since  your  last  experience) 


2)  How  did  you  divide  your  duties  during  the  test  run? 
Controller  Duties: 


Assistant  Duties: 
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3)  Did  your  approach  involve  sharing  of  radio  communication  duties? 
If  so,  what  communications  were  handled  by  the  each 
controller? 


4)  Did  your  approach  involve  sharing  of  Data  Link  communication 
duties?  If  so,  what  communications  were  handled  by  each 
controller? 


5.  Describe  any  modifications  that  you  made  in  your  approach  to 
controlling  the  aircraft  as  the  traffic  level  increased  during  the 
test  run. 


6.  What  messages  did  you  send  using  Data  Link?  Describe  any 
situations  where  you  were  unable  to  use  Data  Link  for  those 
messages . 
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7.  Describe  any  changes  to  the  TI  list  that  you  made  for  this  test 
run.  (e.g.  change  default,  modify  message  content,  reposition  list, 
suppress  items). 


8.  Were  there  any  situations  where  you  were  unable  to  use  the  Data 
Link  to  send  TI  messages?  (describe) 


9.  Describe  any  changes  that  you  made  to  the  MT  list  for  this  test 
run  (e.g.  change  values,  reposition  list,  suppress  items) 


10.  What  MT  clearances  did  you  use  during  the  test  run?  Did  you 
use  the  menu  bypass  function?  (describe). 
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11.  CONFLICT  RECORD 

A  conflict  is  defined  as  a  loss  of  IFR  separation.  Please  note 
the  ID/s  of  conflicting  aircraft  and  complete  this  page  after  the 
test  run.  Under  "cause  of  conflict"  please  note  whether  the 
conflict  was  a  result  of  pilot  error,  related  to  the  use  of  Data 
Link,  or  some  other  problem. 


ARRIVAL/FINAL  CONTROLLER  POST-TEST  QUESTIONNAIRE 


Controller  Name: 


In  the  following  three  questions  you  will  be  asked  to  make  all 
possible  comparisons  of  the  four  combinations  of  controller  team 
size  and  communication  condition  that  were  used  in  the  Test  Bed 
simulation  trials.  One  of  the  possible  pairs  is  presented  on  the 
left  and  right  of  each  line.  Place  an  "X"  in  the  space  which 
best  describes  your  view  of  which  of  the  two  combinations  was 
higher  on  the  factor  being  addressed  (Individual  Workload, 
Capacity,  or  Safety) .  If  the  pair  did  not  differ  on  that 
factor,  place  the  "X”  in  the  "Equal"  space. 

The  following  abbreviations  are  used  to  specify  the  four 
combinations : 


1C/V  - 
2  C/V  - 
1C/V&D  - 
2C/V&D  - 


1  Controller,  Voice-Only  Communications 

2  Controllers,  Voice  Only  Communications 

1  Controller,  Voice  and  Data  Link  Communications 

2  Controllers,  Voice  and  Data  Link  Communications 


1)  Compare  each  of  the  following  pairs  of  controller  and 
communication  conditions  on  the  basis  of  INDIVIDUAL  CONTROLLER 
WORKLOAD . 


< — Higher  Workload 


Higher  Workload — > 


Much  Somewhat 

Higher  Higher 


Equal  Somewhat  Much 

Higher  Higher 


1C/V 


2C/V 


1C/V 


1C/V&D 


1C/V 


2C/V&D 


2C/V 


1C/V&D 


2  C/V 


2C/V&D 


1C/V&D 


2C/V&D 
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2)  Compare  each  of  the  following  pairs  of  controller  and 
communication  conditions  in  terms  of  their  IMPACT  ON  SYSTEM 
CAPACITY. 


1C/V 


< — Higher  Capacity 


Higher  Capacity — > 


Much 

Higher 


Somewhat 

Higher 


Equal 


Somewhat 

Higher 


Much 

Higher 


2C/V 


1C/V 


1C/V&D 


1C/V 


2C/V&D 


2C/V 

2C/V 

1C/V&D 


1C/V&D 

2C/V&D 

2C/V&D 


3)  Compare  each  of  the  following  pairs  of  controller  and 
communication  conditions  in  terms  of  their  IMPACT  ON  SYSTEM 
SAFETY. 


< — Higher  Safety 

Higher  Safety — > 

Much 

Somewhat 

Equal 

Somewhat 

Much 

Higher 

Higher 

Higher 

Higher 

1C/V 

2C/V 

1C/V 

1C/V&D 

1  c/v 

2C/V&D 

2C/V 

1C/V&D 

?  c/v 

2C/V&D 

1C/V&D 

2C/V&D 
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STRATEGY  INTERVIEWS 


Instructions  to  Facilitators 

The  purpose  of  the  strategy  interview  is  to  ask  the 
controller  to  compare  Data  Link  and  voice  after  he  or  she 
have  had  a  chance  to  use  both  systems  during  the  twelve  data 
collection  runs.  The  interviews  will  consist  of  two  parts. 

First,  a  series  of  questions  will  be  asked.  Second,  the 
controllers  will  be  prompted  to  provide  examples  of  incidents 
where  they  chose  between  using  Data  Link  or  voice.  This 
second  set  of  questions  will  specifically  focus  on  the  six 
Data  Link  runs  when  controllers  had  a  choice  over 
communication  method. 

Please  take  notes  on  the  replies.  If  you  need  more  room, 
please  continue  on  the  back  of  the  page,  noting  the  question 
number . 


Controller  Name: 


Facilitator  Name: 
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Fart  One  Questions 


1.  What  were  the  differences  in  your  team  strategies  (with 
two  controllers  working  arrival/final)  between  voice  only  and 
Data  Link  with  voice  runs? 


2.  In  which  communication  condition  (voice  only  or  Data  Link 
with  voice)  were  the  team  strategies  more  effective  and  why? 


3.  What  were  the  differences  in  your  individual  strategies 
(with  one  person  working  arrival/final)  between  voice  only 
and  Data  Link  with  voice  runs? 
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4.  In  which  communication  condition  were  your  individual 
strategies  most  effective  and  why? 


5.  What  do  you  think  would  be  most  desirable  in  a  Data  Link 
environment,  sharing  control  of  a  combined  sector  or  working 
separate  arrival/final  sectors?  Why? 


6.  Please  indicate  which  communication  mode  you  used  to  send 
ATC  information  and  instructions  in  the  following  situations 
and  why  you  used  it : 

a)  Communication  of  Terminal  Information  message  (arrival 
sector) 


b)  Altitude  assignment 


c-9 


c)  Heading  change 


d)  Speed  change 


e)  Conflict  resolution  (rectifying  a  loss  of  separation) 


f)  Dealing  with  missed  approaches 


7.  Did  Data  Link  delay  time  affect  your  use  of  Data  Link  in 
the  individual  or  team  control  runs? 
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Part  Two  Questions 


This  type  of  questioning  focuses  on  "critical  incidents" 
which  occurred  during  the  simulation  runs.  A  critical 
incident  is  defined  as  a  challenging  event  which  went  beyond 
the  routine  and  required  that  the  controller  apply  skilled 
ATC  interventions. 

Try  to  review  at  least  two  critical  incidents  from  the 
preceding  six  Data  Link  with  voice  runs  (where  there  was  a 
choice  over  communication  method) .  Please  go  through  the 
steps  on  the  following  pages  when  collecting  information  on 
critical  incidents. 
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Critical  Incident  1 


a)  Select  Critical  Incident 

Ask  the  controller  to  suggest  an  incident  from  the  Data  Link 
runs  (where  there  was  a  choice  over  using  Data  Link  or  voice) 
which  posed  a  challenging  ATC  problem.  (Please  note  in  which 
run  the  incident  occurred.) 


b)  Obtain  Incident  Report 

Ask  for  a  brief  description  of  the  incident  noting  antecedent 
conditions,  information  available,  and  actions  taken 
(including  decisions  to  use  Data  Link  or  voice) . 
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c)  Construct  Incident  Timeline 

On  a  horizontal  timeline,  note  the  sequence  of  events  of  the 
incident . 


d)  Probe  Decision  Points 

Identify  on  the  timeline  where  decisions  were  made  about  the 
use  of  Data  Link  versus  voice  communication.  Ask  specific 
questions  to  determine  why  Data  Link  or  voice  was  chosen. 
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Critical  Incident  2 


a)  Select  Critical  Incident 

Ask  the  controller  to  suggest  an  incident  from  the  Data  Link 
runs  (where  there  was  a  choice  over  using  Data  Link  or  voice) 
which  posed  a  challenging  ATC  problem.  (Please  note  in  which 
run  the  incident  occurred.) 


b)  Obtain  Incident  Report 

Ask  for  a  brief  description  of  the  incident  noting  antecedent 
conditions,  information  available,  and  actions  taken 
(including  decisions  to  use  Data  Link  or  voice) . 
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c)  Construct  Incident  Timeline 


On  a  horizontal  timeline,  note  the  sequence  of  events  of  the 
incident . 


d)  Probe  Decision  Points 

Identify  on  the  timeline  where  decisions  were  made  about  the 
use  of  Data  Link  versus  voice  communication.  Ask  specific 
questions  to  determine  why  Data  Link  or  voice  was  chosen. 
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